<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE message PUBLIC
  "-//MLarc//DTD MLarc output files//EN"
  "../../mlarc.dtd"[
  <!ATTLIST message
    listname CDATA #REQUIRED
    title CDATA #REQUIRED
  >
]>

  <?xml-stylesheet href="../../mlarc.xsl" type="text/xsl"?>


<message 
  url="2009/10/ef5604af293b4607fcb3dec0a899701a"
  from="Gabriel Kerneis &lt;kerneis@p...&gt;"
  author="Gabriel Kerneis"
  date="2009-10-27T10:01:24"
  subject="Re: [Caml-list] threads, signals, and timeout"
  prev="2009/10/efd377563eab3829b13e555073cb0c13"
  next="2009/10/cbdd8317941f2f2afc1923fe5247492e"
  prev-in-thread="2009/10/7518f0ec43a7d0512807efa6c0e8f252"
  next-in-thread="2009/10/e4edf6464acc506dba82bd0f07a9ce6e"
  prev-thread="2009/10/de24601a1c9d4b35b8c7ad522418043d"
  next-thread="2009/10/cb62aba28e1f84b31e18b738aad34fde"
  root="../../"
  period="month"
  listname="caml-list"
  title="Archives of the Caml mailing list">

<thread subject="threads, signals, and timeout">
<msg 
  url="2009/10/11a0067350cafabdd4315ce510c11474"
  from="yoann padioleau &lt;pad.aryx@g...&gt;"
  author="yoann padioleau"
  date="2009-10-26T18:08:43"
  subject="threads, signals, and timeout">
<msg 
  url="2009/10/87ae3673fe1c6ffe4b22356b236fdc55"
  from="Till Varoquaux &lt;till@p...&gt;"
  author="Till Varoquaux"
  date="2009-10-26T18:36:13"
  subject="Re: [Caml-list] threads, signals, and timeout">
<msg 
  url="2009/10/7be394e1425a4fd37e84d4697217f0f3"
  from="yoann padioleau &lt;pad.aryx@g...&gt;"
  author="yoann padioleau"
  date="2009-10-26T19:06:21"
  subject="Re: [Caml-list] threads, signals, and timeout">
<msg 
  url="2009/10/7518f0ec43a7d0512807efa6c0e8f252"
  from="Gerd Stolpmann &lt;gerd@g...&gt;"
  author="Gerd Stolpmann"
  date="2009-10-26T22:09:35"
  subject="Re: [Caml-list] threads, signals, and timeout">
</msg>
<msg 
  url="2009/10/ef5604af293b4607fcb3dec0a899701a"
  from="Gabriel Kerneis &lt;kerneis@p...&gt;"
  author="Gabriel Kerneis"
  date="2009-10-27T10:01:24"
  subject="Re: [Caml-list] threads, signals, and timeout">
</msg>
</msg>
</msg>
<msg 
  url="2009/10/e4edf6464acc506dba82bd0f07a9ce6e"
  from="Philippe Wang &lt;philippe.wang.lists@g...&gt;"
  author="Philippe Wang"
  date="2009-10-26T23:13:25"
  subject="Re: [Caml-list] threads, signals, and timeout">
</msg>
</msg>
</thread>

<contents>
On Mon, Oct 26, 2009 at 12:06:18PM -0700, yoann padioleau wrote:
&gt; I want to write a toy program that uses threads and timeouts in an
&gt; easy way. Those threads may make heavy use of CPU or IO, I don't know.
&gt; I just want an easy API for thread and timeout.
&gt; 
&gt; To be honest, the problem I have to solve is not in OCaml, but I
&gt; thought OCaml programmers would give better answers than C programmers

Looks like CPC[1] is the perfect tool for you: cooperative threads in C,
with the ability to "detach" a thread for CPU intensive operations (i.e.
make it a native preemptive thread), compiled to sequential event-driven
C code (using continuations). In other words, this is some kind of Lwt
for C, with a thread API (instead of the monadic API of Lwt).

But the timeout problem remains: we have a strong feeling that
cooperative threads is the right way to go, and that you should not be
interrupted anywhere (especially in C, where you don't have any GC to
clean-up your malloc'ed variables, file descriptor, etc.). So you have
to be explicit about where the timeouts can happen, e.g. polling
(cooperatively) some condition variable. We are trying to improve the
timeouts handling in CPC at the moment, so we would be glad to get more
details on what you are trying to do exactly, and how we could solve it.

A sample implementation of timeouts can be found in the io.cpc file of
the Hekate BitTorrent seeder[2].

Since this becomes a bit off-topic, I have to mention the fact that the
compiler is written in OCaml (upon the CIL library) ;-)

[1] http://www.pps.jussieu.fr/~jch/software/cpc/
[2] http://www.pps.jussieu.fr/~jch/software/hekate/

NB: please keep in mind that CPC is a research prototype, suitable for
a "toy program" like yours, or even serious ones like Hekate, but it
would not be reasonable to develop industrial software with it at the
moment.

Regards,
-- 
Gabriel Kerneis

</contents>

</message>

