On Sat, 24 Jan 2009 22:57:41 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Enrico Tröger a écrit :
On Wed, 21 Jan 2009 21:55:33 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hey,
But I /can/ always reproduce the bug if I save and type at a very fast speed, such as chain <letter><^S> about 4 times per second or so – but who's saving its buffers between every letters when typing?
Now for me, if it remains possible to reproduce the bug, it seems not in real world.
Yes, it was also hard for me to reproduce but I got it. It happens when you save a document quickly after the last save process. The 'file has changed' notification takes a moment (I didn't measured it but I'd say something about 0.5-1 sec) until it is triggered. So there is a little time frame where the state is inconsistent and this time frame is hit when saving really fast continuously. For me, it is practically impossible to hit this in a normal work flow. But the time frame might be significantly larger on other systems, not sure by what factors it is influenced. One of the main factors is probably the used file alteration system, as mentioned before it can FAM, Gamin or nothing (i.e. usual file polling). And then FAM and Gamin can use the kernel's inotify (which probably only exists on Linux) or they also do just polling. And there are probably other possibilities.
I've got it one time yesterday, but it was with an uncommon action (resulting on saving 2 times in ~1sec). The I agree it is unstable and not suitable for a release now.
But to solve the problem due to latency, can't a "stack" help? I mean instead of just marking to ignore next notification, increment a "notify_skip" when saving and decrement it on notification received, then only use notification if notify_skip is equal to 0. I think it should work if the problem is only receiving first notif after second save, and it is pretty easy to implement as you said there's already a flag.
Yup, something like this could work, good idea. I'll play with that after the next release.
This week, I also played with delaying the received events to 'collect' them and after some time has passed, check what we received and react approrpiately. But this also failed badly :).
Regards, Enrico