Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[fam\]\s+Fam\s+race\s+condition\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[fam\]\s+Fam\s+race\s+condition\s*$/: 22 ]

Total 22 documents matching your query.

1. [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Tue, 2 Oct 2001 16:30:51 -0400 (EDT); I found a pretty bad race condition in fam. If several changes are made to one file in the same second, fam will only report the first one. It does not detect the following ones, because the resoluti; /archives/fam/2001-10/msg00000.html (8,465 bytes)
2. Re: [fam] Fam race condition (score: 1): Author: Carsten Haitzler (The Rasterman) <raster@xxxxxxxxxxxxx>; Date: Wed, 3 Oct 2001 09:21:10 +1000; On Tue, 2 Oct 2001 16:30:51 -0400 (EDT) Alex Larsson <alexl@xxxxxxxxxx> babbled likely they havent heavily tested the "polling" mode - and rely on the kernel layer (imon) to do the work. i think they; /archives/fam/2001-10/msg00001.html (11,142 bytes)
3. Re: [fam] Fam race condition (score: 1): Author: Wesley Smith <wessmith@xxxxxxx>; Date: Tue, 02 Oct 2001 18:27:41 -0700; Yes, you're right about that - we almost always use imon. But actually, we did run into this problem last year on some internal machines where fam was watching some large mail files. The fix for IRIX; /archives/fam/2001-10/msg00002.html (9,757 bytes)
4. Re: [fam] Fam race condition (score: 1): Author: "Rusty Ballinger" <rusty@xxxxxxxxxxxxxxxxxx>; Date: Wed, 3 Oct 2001 00:27:12 -0700; Even when you're using imon, the idea isn't that you get one event per file operation. (imon has code which intentionally notifies the client only once when multiple operations of the same type happ; /archives/fam/2001-10/msg00003.html (9,094 bytes)
5. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 10:31:16 -0400 (EDT); I know that. But one last event must be sent after the final modification, or clients will "hang" showing an "invalid" state. This happened for us in Nautilus. When saving a file fam sent an event fo; /archives/fam/2001-10/msg00004.html (9,672 bytes)
6. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 10:32:35 -0400 (EDT); This has nothing to do with polling mode. (Well. The bug exists there too, but is much harder to trigger.) / Alex -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscri; /archives/fam/2001-10/msg00005.html (8,609 bytes)
7. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 10:39:58 -0400 (EDT); They're apparently adding that for 2.5. That will sort of solve the problem, if you have 'real' nanosecond resolution timers. Since I doubt that is the case though, I think the correct fix would be t; /archives/fam/2001-10/msg00006.html (9,223 bytes)
8. Re: [fam] Fam race condition (score: 1): Author: Paul Jackson <pj@xxxxxxxxxxxx>; Date: Wed, 3 Oct 2001 12:40:58 -0700; Too bad the event isn't sent at the end of the second, not when the first change is seen. That is, the semantics of the event should be "1 or more changes seen in last second", not "1 or more changes; /archives/fam/2001-10/msg00007.html (8,968 bytes)
9. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 16:50:07 -0400 (EDT); Unfortunately, that would delay reported changes up to one second. That is a user-visible amount of delay. / Alex -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscri; /archives/fam/2001-10/msg00008.html (9,066 bytes)
10. Re: [fam] Fam race condition (score: 1): Author: Paul Jackson <pj@xxxxxxxxxxxx>; Date: Wed, 3 Oct 2001 14:01:20 -0700; ... continuing to brainstorm ... how about both then, meaning to notify on first event, and continue to notify once per second until an entire second elapses with no further events. ... or perhaps th; /archives/fam/2001-10/msg00009.html (8,745 bytes)
11. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 18:30:42 -0400 (EDT); This would mean always duplicating events. Once for the initial event and once at the end of the second. Huh? How would you do that? You are still unable to detect any changes in the last nine tenths; /archives/fam/2001-10/msg00010.html (8,986 bytes)
12. [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Tue, 2 Oct 2001 16:30:51 -0400 (EDT); I found a pretty bad race condition in fam. If several changes are made to one file in the same second, fam will only report the first one. It does not detect the following ones, because the resoluti; /archives/fam/2001-10/msg00038.html (8,480 bytes)
13. Re: [fam] Fam race condition (score: 1): Author: Carsten Haitzler (The Rasterman) <raster@xxxxxxxxxxxxx>; Date: Wed, 3 Oct 2001 09:21:10 +1000; On Tue, 2 Oct 2001 16:30:51 -0400 (EDT) Alex Larsson <alexl@xxxxxxxxxx> babbled profusely: likely they havent heavily tested the "polling" mode - and rely on the kernel layer (imon) to do the work. i; /archives/fam/2001-10/msg00039.html (11,253 bytes)
14. Re: [fam] Fam race condition (score: 1): Author: Wesley Smith <wessmith@xxxxxxx>; Date: Tue, 02 Oct 2001 18:27:41 -0700; Yes, you're right about that - we almost always use imon. But actually, we did run into this problem last year on some internal machines where fam was watching some large mail files. The fix for IRIX; /archives/fam/2001-10/msg00040.html (9,858 bytes)
15. Re: [fam] Fam race condition (score: 1): Author: "Rusty Ballinger" <rusty@xxxxxxxxxxxxxxxxxx>; Date: Wed, 3 Oct 2001 00:27:12 -0700; Even when you're using imon, the idea isn't that you get one event per file operation. (imon has code which intentionally notifies the client only once when multiple operations of the same type happ; /archives/fam/2001-10/msg00041.html (9,198 bytes)
16. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 10:31:16 -0400 (EDT); I know that. But one last event must be sent after the final modification, or clients will "hang" showing an "invalid" state. This happened for us in Nautilus. When saving a file fam sent an event fo; /archives/fam/2001-10/msg00042.html (9,714 bytes)
17. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 10:32:35 -0400 (EDT); This has nothing to do with polling mode. (Well. The bug exists there too, but is much harder to trigger.) / Alex -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscri; /archives/fam/2001-10/msg00043.html (8,662 bytes)
18. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 10:39:58 -0400 (EDT); They're apparently adding that for 2.5. That will sort of solve the problem, if you have 'real' nanosecond resolution timers. Since I doubt that is the case though, I think the correct fix would be t; /archives/fam/2001-10/msg00044.html (9,263 bytes)
19. Re: [fam] Fam race condition (score: 1): Author: Paul Jackson <pj@xxxxxxxxxxxx>; Date: Wed, 3 Oct 2001 12:40:58 -0700; Too bad the event isn't sent at the end of the second, not when the first change is seen. That is, the semantics of the event should be "1 or more changes seen in last second", not "1 or more changes; /archives/fam/2001-10/msg00045.html (9,031 bytes)
20. Re: [fam] Fam race condition (score: 1): Author: Alex Larsson <alexl@xxxxxxxxxx>; Date: Wed, 3 Oct 2001 16:50:07 -0400 (EDT); Unfortunately, that would delay reported changes up to one second. That is a user-visible amount of delay. / Alex -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscri; /archives/fam/2001-10/msg00046.html (9,130 bytes)

Current List: 1 - 20
Page: [1] [2]