From: Alex Baretta <alex@barettadeit.com>
To: Eijiro Sumii <eijiro_sumii@anet.ne.jp>, Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] select (or polling) on in_channel?
Date: Tue, 05 Apr 2005 07:49:03 +0200 [thread overview]
Message-ID: <425226CF.80708@barettadeit.com> (raw)
In-Reply-To: <20050404.162414.18571932.eijiro_sumii@anet.ne.jp>
Eijiro Sumii wrote:
> Thanks to everyone for ideas on how to "select" Pervasives.in_channel.
> Since there seems to be no better solution than
>
> (1) hacking the low-level structure by using external C, or
>
> (2) reinventing the high-level library on top of Unix I/O,
> ...
I have not been following this thread closely, so I did not answer
earlier. My impression is that select and buffered IO are concepts that
do not live well together. I This is probably the reason the Caml team
has for not implementing such a feature in the Pervasives channels API.
I would attempt to model the problem in a multithreaded paradigm, where
the the "selecting" is implicit in the thread scheduling mechanism. Of
course, if you allow the use of threads, the selecting on channels
becomes fairly trivial.
let (++) x f = f x
let input_string =
let buf = String.create 1024 in
fun ic ->
let bytes = input ic buf 0 1024 in
String.sub buf 0 bytes
module IO_manager = struct
type tio_manager = string Event.channel
let wrap_in_channel (evch : io_manager) (ic : input_channel)=
let rec cycle () =
ic ++ input_string ++ Event.send ++ Event.sync;
cycle ()
in Thread.create cycle ()
end
Of course, this is a very rough sketch of message_passing API based on
the Event module, encapsulating the select facility on top of an
input_channel. Actually, ic could be any resource the program might need
to synchronize on.
Let me add that Baretta DE&IT is using this paradigm to multiplex IO
from/to different field buses in its Ocaml based, SoftPLC / SoftCNC kernel.
Alex
--
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL
tel. +39 02 370 111 55
fax. +39 02 370 111 54
Our technology:
The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>
The FreerP Project
<http://www.freerp.org/>
next prev parent reply other threads:[~2005-04-05 5:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-31 23:28 Eijiro Sumii
2005-04-01 10:59 ` [Caml-list] " Gerd Stolpmann
2005-04-01 13:37 ` Eijiro Sumii
2005-04-03 14:43 ` Christoph Bauer
2005-04-04 20:24 ` Eijiro Sumii
2005-04-04 21:29 ` Eijiro Sumii
2005-04-05 5:49 ` Alex Baretta [this message]
2005-04-05 13:34 ` Eijiro Sumii
2005-04-05 14:14 ` Alex Baretta
2005-04-05 18:07 ` Eijiro Sumii
2005-04-05 14:30 ` Richard Jones
2005-04-05 18:12 ` Eijiro Sumii
2005-04-05 7:00 sejourne kevin
2005-04-05 13:39 ` Eijiro Sumii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=425226CF.80708@barettadeit.com \
--to=alex@barettadeit.com \
--cc=caml-list@inria.fr \
--cc=eijiro_sumii@anet.ne.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox