Re g_error() in g_private_new_win32_impl

[Tor Lillqvist]

Tim Janik writes:
  i'd recommend to move to some other error mechanism (stderr printf +
  abort(), etc.) for the scope of this function. 

OK. I'll change it to throw up a MessageBox() instead (printing to
stderr would go unnoticed for most real applications), then abort().

I'll also take away the Use GStaticPrivate instead part of the error
message. That isn't useful to an end user, and for developers the Too
many GPrivate allocated. Their number is limited to %d should be
enough.

  also, i think the private-max setting is rather small:
  gthread/gthread-win32.c:#define G_PRIVATE_MAX 16

I'll increase it to, uh, let's say 100?

  for what it's worth, glibc allowes around 1024 keys to be created
  with pthread_key_create().

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?

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.

(In much earlier times pthreads-win32 was indeed used. I can't recall
why it was dropped and gthread-win32.c written instead. Maybe
pthreads-win32 was too buggy at that time (2001), or it was just felt
that the external depencency was bad.)

--tml

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Re g_error() in g_private_new_win32_impl

[Dominic Lachowicz]

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