Re: thread safe gtk?

[Rob Browning <rlb cs utexas edu>]

Owen Taylor <owen@gtk.org> writes:

> Looking into them in more detail, they have a ~15% overhead, which,
> considering that they are pretty fast to begin with isn't too
> important. However, the interface for recursive locks doesn't seem to be
> very standardized yet. (LinuxThreads uses pthread_mutex_setkind,
> other places it seems to be pthread_mutex_settype, etc.) So it
> might be better to stick with non-recursive locks for now.

The overhead's not serious, but the lack of standardization could be.
We can always add recursive locking as a later option...

> Perhaps it has changed? The current code seems to be pretty
> clearly FIFO. (Its queues keep separate head and tail pointers,
> enqueue at the tail and dequeue at the head).

Maybe so, or I wasn't paying enough attention...

> If one of the subsidiary threads does something that results
> in an idle function being added, the idle function won't
> be processed until the main loop wakes up out of the select()
> of its own accord.

Good point.

>  - Use a pipe to signal the main thread to wake up. Probably the
>    best approach. Not terribly efficient but you only need to
>    do this when adding the first idle handler.
>
>  - Handle the idles in a separate thread to avoid having to
>    wake up the main thread at all. Probably a waste of a process,
>    and somewhat tricky synchonization.

I'd say one of these two approaches would be best.  You pick :>

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30