Re g_error() in g_private_new_win32_impl

[Tor Lillqvist <tml iki fi>]

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