Hi Tor, > BTW, the pthreads-win32 POSIX thread implementation from > http://sourceware.org/pthreads-win32/ just uses native thread-local > storage slots as allocated by TlsAlloc() in its implementation of > pthread_key_create(). The number of those is 1088 per process in > Windows 2000 and newer, and under 100 in Win9x. Maybe gthread-win32 > should do the same. > > On the other hand, instead of thus rewriting significant parts of > gthread-win32.c, maybe it would make sense to simply start using the > pthreads-win32 implementation underneath, i.e. use gthread-posix.c on > Windows, too?
FWIW, my company makes heavy use of pthreads-win32 in our server products without any issues. It "just works". They ship 4 DLLs - GCC, MSVC, GCC+SEH, MSVC+SEH (SEH = "structured exception handling"). If we decided to use this, we'd probably want to use the non-SEH version, as that bit isn't portable across pthreads implementations or across GCC/MSVC compilers. The authors also recommend against using SEH for these reasons. AFAIK, the GCC/MSVC non-SEH DLLs are binary compatible with each other; they're just built using different compilers. http://sourceware.org/pthreads-win32/faq.html The library is actively maintained, FOSS, has gotten a lot more attention than gthread-win32.c (especially, as Tor mentions, with respect to corner cases), and could piggy-back on glib's robust gthread-posix implemenation. > pthreads-win32 seems to be much more carefully written than > gthread-win32, for instance the recently fixed problem related to the > details of GPrivate destructor calling wouldn't have happened with > pthreads-win32. Using it would mean one more external dependency, > though, although it's just one DLL at run-time. Adding one more DLL to the Win32 GTK+ installers shouldn't be an issue. gladewin32 ships with at least 52 DLLs in its bin directory alone, for instance. This includes iconv, intl, zlib, bz2, charset, gettext, asprintf, and other glib/gtk dependencies. Best, Dom -- Counting bodies like sheep to the rhythm of the war drums.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list