> 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to