Re: fork() and progress bar...

[Skip Montanaro <skip pobox com>]

    Valdis> There's a reason to avoid using a slightly-different API -
    Valdis> support costs.  If gthreads had a different thread model than
    Valdis> Posix pthreads, it would be one thing.  But requiring the
    Valdis> support crew to learn pthreads *and* gthreads when there's no
    Valdis> real advantage to it is just wasteful.

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?

-- 
Skip Montanaro (skip pobox com)
http://www.mojam.com/
http://www.musi-cal.com/