Thread wedge ok. Include example? Wrapper generator?
jehenrik at yahoo.com
Tue Jul 3 20:46:08 CEST 2001
Thanks. Fixed. Now I can move on to something useful.
Shouldn't there be an intact threaded example file? Something as simple as the thing that I wrote? I know there's some vague talk
of threading in the README, and some cryptically commented out thread commands in two of the examples, but I still don't see how I
could have known this without reading the .ml source and also . (Which I have had to do a lot anyway, and I don't mind if its
obvious and hard to get wierd runtime behavior, but I'm not sure this one was.)
New issue: Can I ask a question about the design of lablgtk? Why didn't you use/write a wrapper/stub generator to get the lowest
level functionality in LablGTK? Obviously you need Ocaml-style objects on top of that, but it seems like huge amounts of C-code
basically had to be written ad-hoc, and will have to be rewritten again for Gtk 2.0. I have been meaning to do a Ocaml backend for
SWIG. I know that SWIG is not quite as purist as most Ocaml philosophy, but I for one don't want to write a quasi-C++ parser to do
better, and I would argue that at the function interface level, a library really shouldn't be that smart. Just marshalling data,
and in this case doing runtime checks on the dynamic nature of GTK to keep the static typed world of Ocaml on the level. However,
I am somewhat a Ocaml newbie and probably don't see some of the larger issues. Do you think you could have used a SWIG backend to
do lablgtk and saved any time or helped maintainability?
> -----Original Message-----
> From: Jacques Garrigue [mailto:garrigue at kurims.kyoto-u.ac.jp]
> Sent: Tuesday, July 03, 2001 5:49 AM
> To: jehenrik at yahoo.com
> Cc: lablgtk at kaba.or.jp
> Subject: Re: answer to "Thread wedge in lablgtk" is for a different
> From: "Jeff Henrikson" <jehenrik at yahoo.com>
> > My message was actually a reference to one I sent a few days before.
> > The "pointer motion" discrepancy between Linux and Windows was a
> > comment on the old rather than a new problem. (See the earlier
> > message.) All I want to do is get a thread to trigger a paint
> > message. But what happens is that after the first paint, the thread
> > that sends periodic paint messages gets stuck.
> Sorry, I didn't understand your problem.
> The answer is even simpler: with threads, you must use GtkThread.main
> in place of GMain.Main.main, otherwise the gtk mainloop will lock.
> If you use the toplevel, a thread is automatically started, so you
> will have two mainloops running simultaneously, but that seems OK (I'm
> wondering why...)
More information about the Lablgtk-list