Re: [Caml-list] Unix.file_descr -> int ???

[Basile STARYNKEVITCH <basile.starynkevitch@cea.fr>]

>>>>> "Xavier" == Xavier Leroy <xavier.leroy@inria.fr> writes:

 [[citing Max Kirillov <max630@mail.ru> cited by  Bruno.Verlyck@inria.fr]]

    >> Suddently, I'm unable to recover file descriptor from Unix's
    >> file_descr. At least, Unix module does not contain any function
    >> doing that and the type is abstract.  What was a reason for the
    >> limitaion?

    Xavier> Well, because file descriptors are an abstract data type.
    Xavier> What makes you think that they are integers?  None of the
    Xavier> integer operations make any sense on file descriptors,
    Xavier> e.g. adding or multiplying two file descriptors.

    Xavier> It is true that under Unix, file descriptors happen to be
    Xavier> implemented as integers, but that's purely accidental.
    Xavier> E.g. under Windows, Unix.file_descr is not implemented by
    Xavier> integers.

I agree with Xavier that file descriptors are [somehow] an abstract
type. However, in *Unix* (I am talking of Unix only, more precisely
Linux) it is legitimate to pass the file descriptor number to (e.g.) a
child process. Of course adding or substracting file descriptors has
generally no sense [but there are ugly exceptions: imagine a program
whose calling convention requires 2 fds which are guaranteed to be
consecutive numbers]

For example, I will very soon add in my program (opensource GPL-ed,
see www.poesia-filter.org and its CVS repository
PoesiaSoft/PoesiaMonIcap) some code which

1. Create three pipes (using the pipe(2) system call) I O and C

2. Fork(2) a child process

3. in the child process execve(2) a program passing it the file
   descriptors of I (read-end, i.e. the first file descriptor returned
   by pipe) O (write-end, i.e. the second file descriptor returned by
   pipe) and C (read-end). For instance, it may execve a program
   /usr/libexec/poesiafilter/nlp_italian and passes it as arguments
	 arg[0] = "nlp_italian"   
	 arg[1] = "-i"
	 arg[2] = "5"
	 arg[3] = "-o"
	 arg[4] = "7"
	 arg[5] = "-c"
	 arg[6] = "8"
	 arg[7] = "-C"
	 arg[8] = "/etc/poesia/nlp_italian_config"
	 arg[9] is the null pointer
and the 5, 7, and 8 are file descriptors number. This seems a
legitimate use of file descriptors (there are some Unix programs which
does that).

The program (which I call the Poesia monitor) which does this
Unix-pecular stuff is coded in Ocaml. Obviously it requires a
conversion from Unix.file_descr to either integer or strings. If the
child program where coded in Ocaml (and some might be), they will need
a mean to convert a numerical string arguments (like above arg[4] =
"7") to a Unix.file_descr

I think that Ocaml's Unix module should provide all the hooks to do
any Unix programming.

And yes, I know that Unix file descriptors are not really pure or
mathematically elegant. I will even add that the very idea of files
(at least viewed, as in Unix, as a stream of bytes) is debatable. In
an ideal word, we should have orthogonally persistent objects [Curious
readers might look e.g. inside http://www.tunes.org/ for that matter]
and should not deal with dirty things like files. Sadly, the real
world use Unix and Windows :-( sometimes, and use files, sockets,
etc...

We really need something like 
  val ugly_filedescr_of_int: int -> Unix.file_descr
  val ugly_int_of_filedescr: Unix.file_descr -> int

and I'll guess that in practice they both could be (in that very
precise case, for a Unix plateform) defined as Obj.magic suitably
"casted".

The most important debate is: should Ocaml give access to all Unix
ugliness (and dirty tricks)? I think that for pragmatic reasons the
answer should definitely be yes. Ocaml targets not only academia but
also the real world (otherwise, the Ocaml consortium has no sense).

regards


N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique * France
DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX 
phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359
work email: Basile point Starynkevitch at cea point fr 
home email: Basile at Starynkevitch point net

-------------------
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/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners