caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Eijiro Sumii <eijiro_sumii@anet.ne.jp>
To: caml-list@inria.fr
Cc: gerd@gerd-stolpmann.de, sumii@saul.cis.upenn.edu
Subject: Re: [Caml-list] select (or polling) on in_channel?
Date: Fri, 01 Apr 2005 08:37:00 -0500 (EST)	[thread overview]
Message-ID: <20050401.083700.125103382.eijiro_sumii@anet.ne.jp> (raw)
In-Reply-To: <1112353164.6180.10.camel@localhost.localdomain>

Thanks for the reply!

From: "Gerd Stolpmann" <gerd@gerd-stolpmann.de>
> Yes. The point is that you cannot interpret the result of Unix.select in
> a reasonable manner. When Unix.select says the descriptor has no data,
> it might still the case that there are data in the buffer.

Yes, this is what I thought.

> If the descriptor has data, you don't know when they are exactly
> read into the buffer.

Here I don't quite understand what you mean - does this issue per se
prevent us from polling an in_channel?

> I don't understand why you mention in_channel_length here.

If the channel were a (binary) file, I could use in_channel_length to
know how many bytes I should read (by Pervasives.really_input, for
example).

> What is your real problem?

In my program, I need to wait _only for 60 seconds_ for data from a
channel created by Unix.open_connection.  For this purpose, something
like Unix.select would be the best if it worked.

Assuming that no such function like Unix.select exists for
Pervasives.in_channel, I've written the following ad hoc external
function, which can be used (in combination with Unix.select) to
achieve similar effects.  Of course, it might be unsafe if the channel
structure is different in other versions of OCaml.  Any better idea,
anyone...?

	Eijiro

----------------------------------------------------------------------
#include <sys/types.h>
#include <caml/mlvalues.h>

/* adapted from ocaml-3.08.3/byterun/io.h */
struct channel {
  int fd; off_t offset;
  char * end; char * curr; char * max;
  void * mutex; struct channel * next;
  int revealed; int old_revealed; int refcount;
  char buff[0];
};
#define Channel(v) (*((struct channel **) (Data_custom_val(v))))

value in_channel_is_empty(value vc) {
  struct channel *c = Channel(vc);
  return Val_int((c->curr >= c->max) ? 1 : 0);
}


  reply	other threads:[~2005-04-01 13:37 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 [this message]
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
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=20050401.083700.125103382.eijiro_sumii@anet.ne.jp \
    --to=eijiro_sumii@anet.ne.jp \
    --cc=caml-list@inria.fr \
    --cc=gerd@gerd-stolpmann.de \
    --cc=sumii@saul.cis.upenn.edu \
    /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;
as well as URLs for NNTP newsgroup(s).