Re: [gtk-list] Re: thread safe gtk?

[Rob Browning <rlb cs utexas edu>]

I've moved this back to gtk-list because if I understand you
correctly, the latter stuff is definitely an improvement.

"M.Stekelenburg" <root@cal052304.student.utwente.nl> writes:

> not entirely, If you have a thread monitoring the net, which should
> warn you if there is a problem and be quiet if not. gtk will be
> monitoring the select in gdk and sometimes do something (?) What i
> expect is that i've to wake it(by moving the mouse through the
> window or something like that) before it gives the other thread a
> chance.

(If I understand your suggestion below, this bit may be moot) I'm not
sure I understand exactly, but why would you have to move the mouse?
Gtk should call the work proc whenever it doesn't have anything else
to do, and if you need even better than that -- *immediate*
responsiveness from activity on the pipe, then do it from a separate
thread.  That thread will wake up immediately, and then do whatever it
wants with the GUI.  The largest delay possible would be if the GUI
was busy, and you had to wait until the next call of the work proc so
it can releases the global X mutex.  This should be pretty brief.

> The use of sleep is also not my preference however it doesn't cost, it
> only decreases performance of this thread. But if this thread is very
> active...
>
> Looks like i still have to use gdk_input_add to make it monitor in its 
> own select my pipe so i can wake it up.
> But i think that useing your locking around the X calls will simplify
> the calls for complex multithreaded programs. maybe it should be come:
>
> #define XSTART write(Xpipe[1],"x",1);lock(xlock);
> #define XEND   unlock(xlock);
>
> somewhere in the beginning:
> pipe(Xpipe);
> gdk_input_add(Xpipe[0],GDK_INPUT_READ,threadcall,0);
>
> threadcall(){
>   unlock(xlock);
>   read(Xpipe[0],&c,1);
>   lock(xlock);
> }
>
> If this doesn't work a heavier construction with threadconditions is
> possible but i'm just trying to get rid of that one... The problem with
> thread conditions is that you have to use the same threadcondition in both
> threads...

Now this is quite clever.  If I understand correctly, you're having it
select on the actual X pipe, right, so that you'll wake up whenever
there's something for X to do?  If so, that would definitely be a
better approach.  I'm wondering if it might be worth wrapping all this
stuff up into a small API for people using threaded GTK, or if it's
even possible to do that generally.


Something like

  gtk_threaded_main();
  gtk_thread_enter();
  gtk_thread_exit();
  etc...

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