Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Re: SysThreads and DLL's
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David McClain <barabh@q...>
Subject: [Caml-list] Re: SysThreads and DLL's
Okay, after some experimenting here is what I found out about OCaml and
LispWorks Lisp...

1. I set up a test in both languages that executes a nearly infinite loop to
generate massive amounts of garbage -- hence to force many GC operations.
Threading is not explicitly used in either of these two programs, although
the OCaml program was compiled with the -thread option and linked with the
native thread libraries. However, since I never initialize the threading
package (I have them initialize only when used with the Lazy.force trick),
the threading engine of OCaml should not be running.

2. I packaged these two programs up as DLL's for Win/NT 4.0

3. I wrote a simple C driver program to link to these DLL's, initialize
them, and the spawn a raft of threads to exercise that infinite loop all at
the same time....

4. LispWorks Lisp survives this test indefinitely. Unfortunately, a positive
result here is actually indeterminate. All I can say is that it hasn't blown
yet....

5. OCaml survives briefly and then gives GC failures. The test is
nondeterministic, and so the failures occur at varying durations of the
test, but OCaml always shows early failures, relative to the Lisp.

6. Realizing that the OCaml GC must make use of thread specific information,
and hence, rendering this test invalid, I set up an umbilical chord between
incoming thread requests and one thread started up explicitly to handle all
OCaml DLL requests. This is simply two event loops, one on a thread started
specially to initialize OCaml and perform all calls into the OCaml code, and
the other is used by the calling thread to await a result from the OCaml
thread. DLL calls are relayed to the OCaml thread by means of PostMessage().

7. Doing this works great! BUT!!! Only one thread at a time can exercise the
OCaml code. And if the code is an infinite loop, none of the other threads
get a chance to run.

8. I suppose that I could have OCaml spawn a bunch of worker threads and
have them ready and waiting for assignments as they come in. I seem to
remember the X-kernel doing something similar for marshalling network
packets up and down the protocol stack. The idea would be to never allow
these threads to die. When they finish an assignment they go back to the
stable to await the next assignment. So that will be my next experiment.

I find it interesting that LispWorks is able to survive this kind of
punishment -- at least for as long as the few minutes duration that I
watched. But, again, this is an indeterminate kind of answer. At least with
OCaml I *know* where I stand!

BTW, the whole point of this exercise is to find a way to seriously shrink
an oppressively burdensome code base written in frightful C/C++ with
STL/ATL/COM/OLE and a bunch of other junk. I have already seen that both
OCaml and Lisp produce roughly comparable shrinkages with improved
capabilities to boot. The shrinkage is roughly 6 to 1.

My test case is a COM/OLE server for translating network system wide
filenames using recursive prefix mappings like Ousterhout used in the Sprite
OS. The C/C++ code is roughly 3 KLOC that I wrote several years ago, plus a
host of machine generated code to go with it. The Lisp and OCaml versions
are roughly 600 LOC.

Interestingly, OCaml is terser than Common Lisp, despite the lack of
built-in richness that Lisp posesses. The syntax of Lisp is just more wordy.
So despite the lack of built-in library routines in OCaml, which I had to
develop by hand, the overall result is roughly the same size between them.
That even included writing an OCaml version of a Lisp-like PATHNAME module
to parse and represent generalized pathnames. In a sense, OCaml is
comparable to typical Scheme languages when it comes to built-in functions
(probably better!).

My experiments with LispWorks have been fruitful, but I have reservations
about using it because of the extreme lack of documentation, and a
demonstrated failure to be robust against punishment. Despite the results of
the test described above, whenever I generate the DLL for the pathname
translations, it always fails to run properly the first time. I have to kill
the process and start up again. Thereafter it runs reliably as far as I can
tell.

But with the OCaml version, it runs first time, every time. Like a real
champ! The only drawback is the need for greater amounts of C wrapper code
to make it into a DLL, and the need to produce a Makefile.

My aim is code base reduction, and ease of generation, because I want to
unload about 300 KLOC onto some unsuspecting maintenance programmer. I need
to get out from under this code burden!!!! So the jury is still out on which
way to go... Code base reduction is the same, ease of use is somewhat better
in Lisp, but robustness is significantly better in OCaml... It also helps to
have the source code!!

Cheers,

- D.McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr