GlGtk + Thread?

[Matthieu Dubuget]

Hello,

I'm using lablgtk installed from godi on a linux box.

I tried to modify the "simple.ml" example (GL sub-directory) in order to
have thread enabled:
- I replaced Main.main by GtkThread.main
- and ran the example with: lablgtk2 -thread gtkThread.cmo simple.ml

Unfortunately, this did not work. No idea why. There is the message
(from the C part?):

GlGtk-WARNING **: could not make current

Any idea?

My initial goal was to try to make a gtk application, with a separated
thread re-drawing the GlGtk area.

Thanks in advance

Matt

_______________________________________________
Lablgtk mailing list
Lablgtk@...
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk

[Jacques Garrigue]

From: Matthieu Dubuget <matthieu.dubuget@...>

> I'm using lablgtk installed from godi on a linux box.
>
> I tried to modify the "simple.ml" example (GL sub-directory) in order to
> have thread enabled:
> - I replaced Main.main by GtkThread.main
> - and ran the example with: lablgtk2 -thread gtkThread.cmo simple.ml
>
> Unfortunately, this did not work. No idea why. There is the message
> (from the C part?):
>
> GlGtk-WARNING **: could not make current
>
> Any idea?
>
> My initial goal was to try to make a gtk application, with a separated
> thread re-drawing the GlGtk area.

I'm not sure of the reason, but it probably means that GL doesn't like
to be called from different threads. Usually this problem of calling
threads rather happens on windows, but apparently with GL this is the
case for Unix too. The solution is to look at the explanations in
GtkThread.mli, and issue all GL related calls through GtkThread.sync
or GtkThread.async.
Note that of course all calls directly from callbacks should be safe
without wrappers, since they are called from the GUI thread
themselves.

Tell us whether it solves your problem.

Cheers,

Jacques

_______________________________________________
Lablgtk mailing list
Lablgtk@...
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk

[Matthieu Dubuget]

Jacques Garrigue a écrit :

> I'm not sure of the reason, but it probably means that GL doesn't like
> to be called from different threads. Usually this problem of calling
> threads rather happens on windows, but apparently with GL this is the
> case for Unix too. The solution is to look at the explanations in
> GtkThread.mli, and issue all GL related calls through GtkThread.sync
> or GtkThread.async.
> Note that of course all calls directly from callbacks should be safe
> without wrappers, since they are called from the GUI thread
> themselves.
>
> Tell us whether it solves your problem.

Thanks for your answer. Unfortunately, it did not work.

I tried to insert sync calls, but could not find where to put them:

The first GL related function is GlGtk.area. But it would seem strange
to call this function through GtkThread.sync? It is in the main thread,
isn't it?

All the other calls are from callbacks.

The GlGtk-WARNING is displayed when the "display" callback is called only.

Even if this callback is a void function.

If I suppress the area#connect#display call, the warning disappears, but
 when the program end, there is a segmentation error.

Salutations

Matthieu


_______________________________________________
Lablgtk mailing list
Lablgtk@...
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk

[Jacques Garrigue]

From: Matthieu Dubuget <matthieu.dubuget@...>
Subject: Re: [Lablgtk] GlGtk + Thread?
Date: Tue, 16 Sep 2008 22:32:14 +0200

> Jacques Garrigue a écrit :
>
> > I'm not sure of the reason, but it probably means that GL doesn't like
> > to be called from different threads. Usually this problem of calling
> > threads rather happens on windows, but apparently with GL this is the
> > case for Unix too. The solution is to look at the explanations in
> > GtkThread.mli, and issue all GL related calls through GtkThread.sync
> > or GtkThread.async.
> > Note that of course all calls directly from callbacks should be safe
> > without wrappers, since they are called from the GUI thread
> > themselves.
> >
> > Tell us whether it solves your problem.
>
> Thanks for your answer. Unfortunately, it did not work.
>
> I tried to insert sync calls, but could not find where to put them:
>
> The first GL related function is GlGtk.area. But it would seem strange
> to call this function through GtkThread.sync? It is in the main thread,
> isn't it?

Actually, if you use "lablgtk2 -thread" an independent GUI thread is
created at startup, and the main thread is not the GUI thread. This
can be confusing, and for this reason I would suggest avoiding it in
non-interactive use. As a matter of fact, if you use the following
command line (just using GtkThread.main in place of Main.main), the
GUI thread is the main thread, and everything works fine without any
sync:

  lablgtk2 -I +threads unix.cma threads.cma gtkThread.cmo simple.ml

But of course this is not very interesting as an experiment, since
there is only one thread. After that you can try creating threads in
callbacks, and see how it works.

I also tried modifying simple.ml to work with lablgtk2 -thread, for a
real experiment. You need to modify the last two lines of the main
function:

  (* show must be called in the GUI thread *)
  GtkThread.async w#show ();
  (* Now wait for the GUI thread to quit *)
  Thread.join GtkThInit.thread

Note that there is no need to create a main loop in this case, since
there is already one running.
Other calls like widget creation and callback connection usually don't
require wrapping, particularly if the parent widget is not shown yet.

Cheers,

Jacques

_______________________________________________
Lablgtk mailing list
Lablgtk@...
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk