Re: fork() and progress bar...

[Havoc Pennington <hp redhat com>]

Skip Montanaro <skip pobox com> writes: 
> Though I've never used gthreads (all my app building is in Python these
> days, which has a fine enough thread package) and very rarely fiddle with
> the gtk source, I did wonder why so many of the glib functions I
> encountered, like g_strdup, just seemed like sugar coating over the standard
> stuff.  Maybe there's some new semantics under the covers, but it was never
> obvious to me why all this had to be reimplemented.  Slightly different
> (m)allocator semantics, perhaps?
> 

g_strdup() uses the GLib allocator, and also strdup() is not portable
and won't exist on many platforms.

In general GLib does not use the same names as the C library when it
implements portability wrappers because that would cause problems - C
libraries change over time, you'd get collisions. For shared libraries
it's appropriate to stay in one's one namespace. Also, as with
g_strdup(), often GLib will use g_malloc() or things along those
lines.

However, the general rule is that if we have a function that's named
the same as the C lib function, it should behave the same way modulo
the standard GLib add-ons (abort on out-of-memory, g_return_if_fail
checks, etc.).

Another issue is that GLib never includes system header files (except
stddef.h and I think one other), because that creates
platform-specific issues with the symbols defined in the headers,
their order of inclusion, etc. Ideally GLib would be featureful enough
to entirely avoid including system headers, which means apps would
always be portable, absent bugs in glib. i.e. app developers couldn't
screw it up.

Havoc