Re: multithreading with gtkada

[David Marceau <davidmarceau@sympatico.ca>]

evangeli wrote:
> 
> hi all
> 
> it seems that gtk doesnt support multi-threading (see
> http://www.faqs.org/faqs/x-faq/part7/section-15.html).
> My problem is the following :
> my app opens a windows, which on the show event launch a task wich makes
> a long computation. The window also contains a cancel button which can
> be pressed to abort this task.The problem is that i would like this task
> to make X-Call, and that is apparently not possible and give me
You clearly are in the cancel button callback function which means your
gtkhandle is busy already. 
Ok you try to call another Xwindow/gtk api service when it's already
busy(you are already in a gtk/xwindow callback for the
buttoncancelevent)
You are also hinting you're doing time-consuming-work within your
gtk-input-window-callback.  I'll get to why you shouldn't be doing this
later.

> unavoidably the following error message:
> ----------------------------------------------
> Xlib: unexpected async reply (sequence 0x9fe)!
> ----------------------------------------------
> i havent found any solution which doesn't use several tasks.
> 
> 1) Am i clear?
> 2) Do u have any idea of a different way to do that?
> 3) why this cruel destiny?
> 
> thanks for any response
Veering away from your problem for a moment, what exactly are you trying
to achieve with your gui without talking directly about ada?
If your intention is something like a progress bar with a cancel button,
have you looked at the demos that came with gtkada?
Essentially in the gtkada demos there is at least one demo that has a
main window which brings up a child progress window with a cancel
button.

Keeping in mind I haven't looked at gtkada recently(although I do like
it), here are the important concepts IMHO:
-I would suggest making your pseudo-progress-window modal because I
recommend you have only one window accepting input from the user at a
time(i.e. with focus and enabled).  Technically every different
gui-control either button/listbox/... is a window but I'm talking about
windows with usually a frame and decorations(i.e.
min/max/close/command-button/resize-edges).  Also known as FrameWindows
or MainWindows or ParentWidgets.  BTW Feel free to correct me if I'm
wrong :)  
-Once you follow that rule then keeping one global gtk handle and
protecting it(protected type) should be enough for you to draw and
update whenever you want from any task.  
-In that manner if a second or Nth task wants to draw, it will wait
until the-busy-drawing-task has unblocked the protected gtk handle.
-You will find more difficulty when dealing with user x input callbacks
from two or more ada tasks coming from two or more different windows. 
What you really want to avoid doing is being in a state where two
buttons in two different windows are pressed simultaneously or even the
same button in one window is pressed very quickly more than once.  This
is hard to do mind you but if you're ada time-consuming-work is actually
called from within the gui callback, you will suffer the consequences. 
Take the gui state, get out of the callback and let another task handle
the state and do the time-consuming-work.  This will avoid
gui-blocking/gui-deadlock and improve gui-responsiveness.  i.e. if you
press some compute button really quick more than once and your
application crumbles to a dead halt, you probably didn't separate the
concerns enough.
-whatever happens don't be afraid of trying stuff because the operating
system won't die.  You might have to re-startx or
win32-logout/win32-login though.  Saving your files before crapping out
your xserver or win32 session is always a good idea :)

I hope this gives you a bit of perspective.  Good luck. 

Sant� bonheur,
David Marceau