> On Sep 19, 2016, at 08:30, Keith Packard <kei...@keithp.com> wrote: > > Jeremy Huddleston Sequoia <jerem...@apple.com> writes: > >> ================== >> WARNING: ThreadSanitizer: data race (pid=4943) >> Read of size 4 at 0x00010c4e3854 by thread T8: >> #0 WaitForSomething WaitFor.c:237 (X11.bin+0x00010049216c) >> #1 Dispatch dispatch.c:413 (X11.bin+0x000100352ed9) >> #2 dix_main main.c:287 (X11.bin+0x00010036e894) >> #3 server_thread quartzStartup.c:66 (X11.bin+0x000100039e63) >> >> Previous write of size 4 at 0x00010c4e3854 by thread T12 (mutexes: write >> M856, write M1976): >> #0 mieqEnqueue mieq.c:263 (X11.bin+0x000100448d14) >> #1 DarwinSendDDXEvent darwinEvents.c:641 (X11.bin+0x000100033613) >> #2 DarwinProcessFDAdditionQueue_thread darwinEvents.c:338 >> (X11.bin+0x000100032039) > > I'm not sure I want to resolve this "bug" -- the event queue has been > designed to be safe in a lockless threaded environment as it was originally > designed to directly map a kernel address which would be modified at > interrupt time. Is there an actual issue with the design?
Yeah, I made the change mainly to shutup the analyzer while I was looking for other races. I decided to propose it in case we want to be strict here. I don't see an absolute need to do this. The code looks perfectly safe to me without this change because the data is only read and compared. There could be issues with reads being nonatomic and getting back some meaningless value, but the outcome of that failure would just be an extra unneeded call into ProcessInputEvents(), which is perfectly safe.
Description: S/MIME cryptographic signature
_______________________________________________ firstname.lastname@example.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel