[Geany-devel] [ geany-Bugs-2519094 ] GFileMonitor and g_object_ref

Enrico Tröger enrico.troeger at xxxxx
Sun Jan 25 15:59:23 UTC 2009


On Sat, 24 Jan 2009 22:57:41 +0100, Colomban Wendling
<ban-ubuntu at 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 at 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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20090125/3bb15bb3/attachment.pgp>


More information about the Devel mailing list