--- Begin Message ---
- From: Drazen Kacar <dave srce hr>
- To: Havoc Pennington <hp redhat com>
- Cc: Drazen Kacar <dave srce hr>, gnome-hackers nuclecu unam mx
- Subject: Re: GNOME code and ANSI C.
- Date: Thu, 5 Oct 2000 04:20:38 +0200
Havoc Pennington wrote: > Drazen Kacar <dave srce hr> writes: > > Are you aware of the fact that GStaticMutex hack is unportable and > > dangerous? > > I'm not personally, I haven't looked at the implementation. I assumed > it would just use the usual select() trick. It does (the g_usleep() function) and that's not the problem. But it locks a mutex before that. Which is also not a problem. The problem is the nature of the mutex. GStaticMutex is, as its name says, a static mutex. At configure time, glib determines the size of the mutex structure and its contents. This information is stored in glibconfig.h. And then those things are used to initialize static mutexes (mutices?), bypassing the only documented way. The current 1.2.x documentation says: A GStaticMutex works like a GMutex, but it has one significant advantage. It doesn't need to be created at run-time like a GMutex, but can be defined at compile-time. AFAIK, if you use mutex like this, standards have to say only one thing: "undefined behaviour." I'm not aware of a single OS which has more to say about it, but I'm not threads expert, so there might actually be some platform which has defined behaviour here. Although I doubt it. You see, it's perfectly possible that pthread_mutex_init() on the same OS initializes mutex structure with the different values for single CPU, SMP, NUMA or COMA systems. Which is one of the reasons why mutex structures are opaque. If that happens, you can throw binary compatibility down the toilet. If I apply a single patch for the kernel, libc or the thread library, nobody guarantees that the app would work any more. I'd never use hacks like this in my code. Since glib does, that means I can't use glib in MT apps. I simply don't have the balls for that. And I don't see a reason for using something like this in the first place. Avoiding a single call to pthread_mutex_init() (or equivalent) doesn't look like a compelling reason. -- .-. .-. I don't work for my employer. (_ \ / _) | dave srce hr | dave fly srk fer hr
--- End Message ---