Thread wedge ok. Include example? Wrapper generator?
garrigue at kurims.kyoto-u.ac.jp
Wed Jul 4 02:55:45 CEST 2001
> 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.)
You're damn right. I completely forgot to explain this in the README.
Well, basically this is about all you have to know about threads: look
in GtkThread.ml, this even shows you the way it is implemented.
Why does it work? Essentially, the ocaml runtime holds a big lock, to
make sure two caml threads do not run simultaneously (the allocator
cannot run concurrently). Since the lock is not returned when calling
GTK functions, you cannot switch to another ocaml thread while
executing GTK code or callbacks. Your only chance to do that is the
Thread.delay 0.001 in GtkThread. Note that if you have other C
threads running, they are not submitted to this constraint, and you
must be careful about not calling callbacks from them.
> 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
History: at the beginning I just started writing stubs to understand
how it all worked. Then I started using lots of C macros to make the
stubd smaller, and less error prone. And I ended-up with a full-fledge
interface, with no real need to start it all again another way.
More pragmatically, I'm not convinced by stub generators, particularly
in the context of functional programming languages. Considering the
semantic gap between the languages, for instance the existence of NULL
pointers in C, you must more or less check function by function that
your semantics is correct. You could first generate and then check,
but it's not necessarily safer.
Another problem is the use of optional parameters. It is often easier
to resolve the default value on the C side (the Option_val macro),
where you have more information. This cannot be generated automatically.
What about Gtk 2.0? Already when upgrading to 1.2 I was very much
tempted to switch to a stub generator. But upgrade proved to be not
that difficult, and I was finished before having started to design the
stub generator. 2.0 is a bigger step, but I think the basic structure
is already there, making it a semi-mechanical work.
> 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.
How smart the lower layer should be is an important point. Make it too
smart, and it comes in the way. Make it too dumb and you will need yet
another layer. LablGTK tries to be in the middle, doing the work where
it is easier to do it.
This is not to deny the interest of SWIG-like approach. When you need
a quick and dirty interface to a library, this would be tremendously
useful. The question is how it scales when you want to clean it up.
More information about the Lablgtk-list