Re: [Caml-list] Thread behaviour

[Romain Bardou <romain.bardou@inria.fr>]

It happens I implemented a library to handle messaging between
possibly-distributed OCaml processes myself. Well, for now one can only
send one message and receive one message: the goal is to be able to run
a function 'a -> 'b in another process, given marshaling functions for
'a and 'b and exceptions. I do plan to add the possibility of sending
more "intermediate" messages (I need it). It works on Linux and Windows.

I did not do any official release yet, but you can have a look here:

https://github.com/cryptosense/procord

You can clone the directory and "make doc" to view the Ocamldoc
documentation in HTML. (I would have put it on my web page but I can't
access it right now.)

In the documentation directory there is a motivation.txt file which
explains the need for the library and compares it to other solutions.

I need this library for a commercial product, so I plan to maintain it
in the long run.

If you plan to build your own library, consider contributing to Procord
instead :) If you don't want to I would be happy to hear what you want
to do differently.

I will present Procord at the next OUPS meeting, and I plan to do an
official release before that. Before, I need to check whether the MIT
license must be copied to every source file or whether a LICENSE file in
the root directory is enough.

Cheers,

-- 
Romain Bardou

Le 28/09/2013 21:09, Tom Ridge a écrit :
> Would it be fair to say that OCaml does not currently support
> pre-emptively scheduled threads?
> 
> I have read the lecture from Xavier archived here:
> 
> http://alan.petitepomme.net/cwn/2002.11.26.html#8
> 
> I would like to implement a library to handle messaging between
> possibly-distributed OCaml processes. Alas, my design naively requires
> pre-emptively scheduled threads (although it may be possible to change
> the design e.g. to work with Lwt) - each message queue is accompanied
> by a thread which reinitializes connections when connections go down
> etc., hiding this complexity from the user.
> 
> Quoting Xavier:
> 
> "Scheduling I/O and computation concurrently, and managing process
> stacks, is the job of the operating system."
> 
> But what if you want to implement a messaging library in OCaml? It
> seems unlikely that all operating systems would fix on a standard
> implementation of distributed message passing (or, even more funky,
> distributed persistent message queues).
> 
> 
> On 27 September 2013 11:51, Benedikt Grundmann
> <bgrundmann@janestreet.com> wrote:
>> The ticker thread will cause yields which will be honored on the next
>> allocation of the thread that currently has the caml lock.  That said we
>> have seen that sometimes the lock is reacquired by the same thread again.
>> So there are some fairness issues.
>>
>>
>> On Fri, Sep 27, 2013 at 11:27 AM, Romain Bardou <romain.bardou@inria.fr>
>> wrote:
>>>
>>> Le 27/09/2013 12:10, Tom Ridge a écrit :
>>>> Dear caml-list,
>>>>
>>>> I have a little program which creates a thread, and then sits in a loop:
>>>>
>>>> --
>>>>
>>>> let f () =
>>>>   let _ = ignore (print_endline "3") in
>>>>   let _ = ignore (print_endline "hello") in
>>>>   let _ = ignore (print_endline "4") in
>>>>   ()
>>>>
>>>> let main () =
>>>>   let _ = ignore (print_endline "1") in
>>>>   let t = Thread.create f () in
>>>>   (* let _ = Thread.join t in *)
>>>>   let _ = ignore (print_endline "2") in
>>>>   while true do
>>>>     flush stdout;
>>>>   done
>>>>
>>>> let _ = main ()
>>>>
>>>> --
>>>>
>>>> I compile the program with the following Makefile clause:
>>>>
>>>> test.byte: test.ml FORCE
>>>> ocamlc -o $@ -thread unix.cma threads.cma $<
>>>>
>>>> When I run the program I get the output:
>>>>
>>>> 1
>>>> 2
>>>>
>>>> and the program then sits in the loop. I was expecting the output from
>>>> f to show up as well. If you wait a while, it does. But you have to
>>>> wait quite a while.
>>>>
>>>> What am I doing wrong here? I notice that if I put Thread.yield in the
>>>> while loop then f's output gets printed pretty quickly. But why should
>>>> the while loop affect scheduling of f's thread?
>>>>
>>>> Thanks
>>>>
>>>
>>> OCaml's thread, unfortunately, are kind of cooperative: you need to
>>> yield explicitly. Note that you will obtain an even different (worse)
>>> result with a native program. I observed this myself without looking at
>>> the thread code itself so maybe there is actually a way to
>>> "automatically yield" but as far as I know there is no way to obtain the
>>> behavior you want without using either yields or processes instead of
>>> threads. This is the reason for the Procord library I am developing
>>> (first version to be released before the next OUPS meeting).
>>>
>>> Also, you don't need to ignore the result of print_endline, as
>>> print_endline returns unit. And using let _ = ... in is the same as
>>> using ignore, so using both is not needed.
>>>
>>> Cheers,
>>>
>>> --
>>> Romain Bardou
>>>
>>> --
>>> Caml-list mailing list.  Subscription management and archives:
>>> https://sympa.inria.fr/sympa/arc/caml-list
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>