Possible race in _dispatch_logv when DISPATCH_DEBUG is defined?
The intended pattern in _dispatch_logv is to have a static FILE* logfile for the log file, lazily initialized by the first thread to call the function. To avoid locking, every thread that sees that logfile is empty opens the log file in a private per-thread FILE*, and then tries to cmpxchg that into the static value. Any thread that loses the race just closes its private copy and uses the shared one. However, tmp has been marked static too, which means that if several threads are executing _dispatch_logv simultaneously, they'll clobber each other's tmp. That seems of dubious value to me; I think tmp should be non-static. Peter
I wouldn't worry about it, once the merge with the Lion changes is done, this initialization will be implemented with dispatch_once_f() (still working on it...) On Jul 4, 2011, at 6:46 PM, DrPizza wrote:
The intended pattern in _dispatch_logv is to have a static FILE* logfile for the log file, lazily initialized by the first thread to call the function. To avoid locking, every thread that sees that logfile is empty opens the log file in a private per-thread FILE*, and then tries to cmpxchg that into the static value. Any thread that loses the race just closes its private copy and uses the shared one.
However, tmp has been marked static too, which means that if several threads are executing _dispatch_logv simultaneously, they'll clobber each other's tmp. That seems of dubious value to me; I think tmp should be non-static.
Peter
_______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
I wouldn't worry about it, once the merge with the Lion changes is done, this initialization will be implemented with dispatch_once_f() (still working on it...)
Oh neato. That does make more sense than the current ad hoc scheme. On the subject of updating the public source, do you happen to know what Apple uses for the libdispatch DLL it ships with certain Windows applications (found at C:\Program Files (x86)\Common Files\Apple\Apple Application Support\libdispatch.dll)? Is there any chance of having that source published?
I'll have to check on that On Jul 4, 2011, at 7:36 PM, DrPizza wrote:
I wouldn't worry about it, once the merge with the Lion changes is done, this initialization will be implemented with dispatch_once_f() (still working on it...)
Oh neato. That does make more sense than the current ad hoc scheme.
On the subject of updating the public source, do you happen to know what Apple uses for the libdispatch DLL it ships with certain Windows applications (found at C:\Program Files (x86)\Common Files\Apple\Apple Application Support\libdispatch.dll)? Is there any chance of having that source published?
I'm very interested about the win DLL as well! Federico On Tue, Jul 5, 2011 at 04:48, Daniel A. Steffen <dsteffen@apple.com> wrote:
I'll have to check on that
On Jul 4, 2011, at 7:36 PM, DrPizza wrote:
I wouldn't worry about it, once the merge with the Lion changes is done, this initialization will be implemented with dispatch_once_f() (still working on it...)
Oh neato. That does make more sense than the current ad hoc scheme.
On the subject of updating the public source, do you happen to know what Apple uses for the libdispatch DLL it ships with certain Windows applications (found at C:\Program Files (x86)\Common Files\Apple\Apple Application Support\libdispatch.dll)? Is there any chance of having that source published?
_______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
Portions of the Windows port are already available (e.g., semaphore.c and time.c). Other pieces have not yet been merged because they are either somewhat disruptive to the code base (i.e. eliminating C99-isms to compile with Visual C++), or fairly unique to Apple (i.e. scripts for our build environment). We do plan on making more available over time, but we're still pondering the best way to maintain the Windows port going forward (we don't want to get rid of C99!). Also, we're excited to merge in some of the great Windows porting work that's been done by this group. As a first step we plan to focus on the POSIX-style platform support and reconcile the FreeBSD/Linux/etc. ports with our Lion changes, then reconcile the Windows ports as a second step. Kevin On Jul 5, 2011, at 12:39 AM, Federico Bianco Prevot wrote:
I'm very interested about the win DLL as well! Federico
On Tue, Jul 5, 2011 at 04:48, Daniel A. Steffen <dsteffen@apple.com> wrote:
I'll have to check on that
On Jul 4, 2011, at 7:36 PM, DrPizza wrote:
I wouldn't worry about it, once the merge with the Lion changes is done, this initialization will be implemented with dispatch_once_f() (still working on it...)
Oh neato. That does make more sense than the current ad hoc scheme.
On the subject of updating the public source, do you happen to know what Apple uses for the libdispatch DLL it ships with certain Windows applications (found at C:\Program Files (x86)\Common Files\Apple\Apple Application Support\libdispatch.dll)? Is there any chance of having that source published?
Portions of the Windows port are already available [...] We do plan on making more available over time, [...] As a first step we plan to focus on the POSIX-style platform support and reconcile the FreeBSD/Linux/etc. ports with our Lion changes, then reconcile the Windows ports as a second step.
That sounds great! Obviously we would love to get Windows changes sooner than later, but I'm very pleased that the project exists at all, and that the Apple engineers are so present on the mailing list to answer questions. I'm very excited for Lion (on my Macs) and for being able to standardize on GCD across all my coding projects! :-) Best regards, -Brent
participants (5)
-
Brent Fulgham
-
Daniel A. Steffen
-
DrPizza
-
Federico Bianco Prevot
-
Kevin Van Vechten