Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] gc question: thread stacks, fibers, etc.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-10-12 (15:58)
From: John Max Skaller <skaller@o...>
Subject: Re: [Caml-list] Coroutines
Jerome Vouillon wrote:

> On Fri, Oct 04, 2002 at 03:25:44AM -0700, Chris Hecker wrote:
>>I'm looking at implementing fibers/coroutines/cooperative-threads 
>>(described below for reference) in ocaml, and I've run into a small issue, 
>>a question, and a couple confusions.
> I just spent a few hours implementing a small coroutine library.  It
> is fully written in Ocaml.  Below is a quick description.  Would it
> satisfy your needs ? I can send you a copy, or make it available on the
> Web if you like.
> -- Jérôme
> A coroutine returning values of type 'a has type 'a output.
>     type 'a output
> You can spawn it.  You then get an handle of type 'a input
>     type 'a input
>     val spawn : 'a output -> 'a input
> The caller can get a value from the coroutine.
>     val receive : 'a input -> 'a
> A coroutine can return a value of type 'a.
>     val send : 'a -> 'a output

These aren't general coroutines, but a subclass I'd call
'filters' corresponding to unix processes with standard input
and output.

[Felix coroutines are even more restricted .. they can read input,
but there is no provision for output.]

Despite the apparent lack of generality,
a very wide class of coroutines can be implemented by careful
choice of the data type 'a, and 'hand written' switches which
provide further coroutine emulation within each library coroutine.

So I think this library has a good interface, indeed,
I'd consider it for the standard distribution. It is simple
and lightweight.

BTW: I note the interface is 'demand driven' .. you make it
work by reading data from the last stage of a filter chain,
and control ripples back to the first input stage.

Felix, on the other hand, is event driven .. you make it
works by sending data to coroutines ..

'Real' coroutines can read and write on multiple channels,
exactly like threads with blocking I/O  except there
is no preemptive switching, obviating the need for
thread safe coding.

Two well known (and very good) implementations:
Windows 3.1 and early Mac OS.

Finally .. you might want to consider JoCaml ..
it is very beautiful (though the implementation using
Posix threads is likely to be slow compared to
native exchange of control primitives)

John Max Skaller,
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: