[Caml-list] Library using blocking Unix functions

[Caml-list] Library using blocking Unix functions

[Nicolas GEORGE]

I am trying to write a small library that needs blocking functions. And I
have a problem with these: they exist in Unix and ThreadUnix. This is not a
problem for a self-contained application, where one know if it is threaded
or not (even there, switching from non-threaded to threaded may cause
errors). But this means that the same library can not be used in both
cases.

One solution could be for _every_ module in the library to be a functor in
term of an ThreadUnix-like module, but I find that hevay and inelegant.

Something more elegant would be, I think, to have a unique module, let us
say BlockingUnix, with two implementations, one in the standard directory,
and another in the directory with the threaded library, that have exactly
the same interface (the .cmi should have the same md5 sum).

I wonder what people here think about this.
-------------------
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

Re: [Caml-list] Library using blocking Unix functions

[Patrick M Doane]

Hello,

If it is reasonable for you to use version 3.01, then I think your problem
is solved.  Here is an excerpt from the manual for the ThreadUnix module:

  This module is deprecated: its functionality has been merged back into
  the Unix module. Threaded programs can now call the functions from
  module Unix directly, and still get the correct behavior (block the
  calling thread, if required, but do not block all threads in the
  process). 

Patrick Doane

On Sun, 24 Jun 2001, Nicolas GEORGE wrote: 

> I am trying to write a small library that needs blocking functions. And
> I have a problem with these: they exist in Unix and ThreadUnix. This is
> not a problem for a self-contained application, where one know if it is
> threaded or not (even there, switching from non-threaded to threaded may
> cause errors). But this means that the same library can not be used in
> both cases. 
> 
> One solution could be for _every_ module in the library to be a functor in
> term of an ThreadUnix-like module, but I find that hevay and inelegant.
> 
> Something more elegant would be, I think, to have a unique module, let us
> say BlockingUnix, with two implementations, one in the standard directory,
> and another in the directory with the threaded library, that have exactly
> the same interface (the .cmi should have the same md5 sum).
> 
> I wonder what people here think about this.
> -------------------
> 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
> 

-------------------
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

Re: [Caml-list] Library using blocking Unix functions

[Nicolas George]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

Patrick M Doane, dans le message
<Pine.BSF.3.96.1010624170601.68472A-100000@fledge.watson.org> a écrit :
> If it is reasonable for you to use version 3.01, then I think your problem
> is solved.  Here is an excerpt from the manual for the ThreadUnix module:
> 
>   This module is deprecated: its functionality has been merged back into
>   the Unix module.

Oops, you are right. I did not re-read the manual when 3.01 was released,
and this is not in the Change file. Thanks. And thanks for the OCaml team,
too.
-------------------
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

Re: [Caml-list] Library using blocking Unix functions

[Xavier Leroy]

> If it is reasonable for you to use version 3.01, then I think your problem
> is solved.  Here is an excerpt from the manual for the ThreadUnix module:
> 
>   This module is deprecated: its functionality has been merged back into
>   the Unix module. Threaded programs can now call the functions from
>   module Unix directly, and still get the correct behavior (block the
>   calling thread, if required, but do not block all threads in the
>   process). 

I'm afraid the documentation is ahead of the source :-(  
ThreadUnix will be deprecated as described above, however this
couldn't be completed in time for the 3.01 release.  I probably forgot
to "de-update" the documentation.

But, yes, the solution to Nicolas' need is to get rid of ThreadUnix
entirely.

- Xavier Leroy
-------------------
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