From: "Nathaniel Gray" <n8gray@gmail.com>
To: "Olivier Andrieu" <oandrieu@nerim.net>
Cc: "Caml Mailing List" <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Re: Select on channels (again)
Date: Tue, 22 Aug 2006 22:27:43 -0700 [thread overview]
Message-ID: <aee06c9e0608222227u1f7e14ebw20f17f284eb97b83@mail.gmail.com> (raw)
In-Reply-To: <17642.48113.637250.34242@karryall.dnsalias.org>
On 8/22/06, Olivier Andrieu <oandrieu@nerim.net> wrote:
> Nathaniel Gray [Monday 21 August 2006] :
> >
> > On 8/21/06, Jonathan Roewen <jonathan.roewen@gmail.com> wrote:
> > > Why can't you just use the unix file opening functions since you're
> > > using unix select? And if you need the ocaml in/out channels, convert
> > > the unix file descriptors to ocaml ones instead of the other way
> > > around. Seems simple enough to me.
> >
> > It sounds simple but doesn't work. If select tells you a file
> > descriptor doesn't have data waiting you can't be sure there isn't
> > still data in the corresponding channel's buffer. See the thread that
> > I referenced for a good discussion of why this is annoying. For one
> > thing, it makes it impossible to use Marshal.from_channel without
> > potentially blocking.
>
> Indeed, Marshal.from_channel would block, but it's not the only way to
> read a marshalled value: cf. Marshal.header_size and
> Marshal.data_size.
>
> With these, you can read your marshalled value from file_descr into a
> buffer in a non-blocking, select-compatible way and then use
> Marshal.from_string.
Yes, as I said, it's possible to work around this limitation by
creating yet another implementation of buffered I/O. My point is that
there's already a good buffered I/O implementation in ocaml that could
suit many (but not all) needs -- channels. Adding channel_select
would make channels a lot more useful at very little expense. Heck, I
would be satisfied with in/out_channel_is_ready, which would be even
easier!
Cheers,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
next prev parent reply other threads:[~2006-08-23 5:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-15 0:46 Nathaniel Gray
2006-08-21 22:47 ` Nathaniel Gray
2006-08-22 0:42 ` [Caml-list] " Jonathan Roewen
2006-08-22 6:27 ` Nathaniel Gray
2006-08-22 6:41 ` Jonathan Roewen
2006-08-22 8:15 ` skaller
2006-08-22 21:15 ` Mike Lin
2006-08-23 5:12 ` Nathaniel Gray
2006-08-22 8:10 ` Olivier Andrieu
2006-08-23 5:27 ` Nathaniel Gray [this message]
2006-08-22 8:21 ` Jacques Garrigue
2006-08-23 5:16 ` Nathaniel Gray
2006-08-23 6:35 ` skaller
2006-08-23 19:31 ` Nathaniel Gray
2006-08-24 5:37 ` skaller
2006-08-24 19:06 ` Nathaniel Gray
2006-08-25 1:55 ` skaller
2006-08-25 22:19 ` Nathaniel Gray
2006-08-23 8:29 Christoph Bauer
2006-08-23 17:35 ` Robert Roessler
2006-08-24 8:18 ` Robert Roessler
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=aee06c9e0608222227u1f7e14ebw20f17f284eb97b83@mail.gmail.com \
--to=n8gray@gmail.com \
--cc=caml-list@yquem.inria.fr \
--cc=oandrieu@nerim.net \
/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