English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Help interfacing with C
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-08-18 (21:33)
From: Nathaniel Gray <n8gray@g...>
Subject: Re: [Caml-list] Re: Help interfacing with C
On 8/16/06, Bardur Arantsson <spam@scientician.net> wrote:
> Nathaniel Gray wrote:
> > Hi folks,
> [--snip--]
> > have select work on (file_descr * 'a) pairs instead of plain file
> > descriptors.
> It's much easier than that; just define a conversion in OCaml:
>     external file_descr_to_int : file_descr -> int = "%identity";
>     external int_to_file_descr : int -> file_descr = "%identity";
> and use
>     let my_select r w e t =
>        let r' = List.map file_descr_to_int r
>        and w' = List.map file_descr_to_int w
>        and e' = List.map file_descr_to_int e
>        in
>          Unix.select r' w' e' t;;
> You seem to be doing the mapping of the result values, but that is just
> a question of mapping int_to_file_descr over the result lists.

Thanks, but this doesn't really help.  Perhaps I should say what I'm
trying to accomplish instead of trying to let the types speak for me.
The point is that when you select on a list of file descriptors
there's a very good chance that you don't *only* care that file
descriptor f is ready, you also have some ocaml data structure
associated with f that you want to use with it in some way.  For
example, you probably have a string to write or a buffer to read into.

The current API is sort of a minimal translation of the select system
call to OCaml, which is a good starting point, but not great IMHO.  In
order to match up each file descriptor to its data you have to scan
the output fd list yet again, after it's already been done once at the
C level, and since you don't know how/if it's sorted you end up with
unsatisfying time complexity for the whole thing.  It's not critical,
since the lists are small, but it hardly brings a smile to your face.

On the other hand, imagine a select2 that takes lists of (fd, 'a)
pairs and returns the same.  The results become incredibly easy to
handle, with no scanning necessary.  You probably just List.iter a
simple read/write function over the result and you're done.

> Of course this may be rather slower than your version, but Unix.select
> is very very slow anyway since it's allocating at least one list for
> every single call... and iterating through all(?) the file descriptors
> in the input FD_SETs as well.
> [Shameless plug below: If you want better performance, you might want
> to try
> http://www.imada.sdu.dk/~bardur/personal/45-programs/ocaml-events/ocaml-events-0.1.0.tar.bz2
> I must warn you, though, that there are no timers or signal handling: It
> turned out I didn't them for my particular application, so I haven't
> bothered adding support. The actual FD polling/selection has worked very
> reliably for me.]

>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->