To: jehenrik at yahoo.com Cc: lablgtk at kaba.or.jp Subject: Re: Thread wedge ok. Include example? Wrapper generator? In-Reply-To: <001801c103f0$6bee53a0$0b01a8c0 at mit.edu> References: <20010703184927P.garrigue at kurims.kyoto-u.ac.jp> <001801c103f0$6bee53a0$0b01a8c0@mit.edu> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010704095545V.garrigue at kurims.kyoto-u.ac.jp> Date: Wed, 04 Jul 2001 09:55:45 +0900 From: Jacques Garrigue Lines: 69 > 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 > SWIG. 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. Cheers, Jacques