From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA27332; Wed, 12 Jun 2002 09:43:12 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA27336 for ; Wed, 12 Jun 2002 09:43:11 +0200 (MET DST) Received: from cirse.saclay.cea.fr (cirse.saclay.cea.fr [132.166.192.127]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g5C7hAj24467; Wed, 12 Jun 2002 09:43:10 +0200 (MET DST) Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.saclay.cea.fr (8.12.2/8.12.2/CEAnet-Internet.1.0) with ESMTP id g5C7iZPl000280; Wed, 12 Jun 2002 09:44:35 +0200 (MEST) Received: from muguet.saclay.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Wed, 12 Jun 2002 09:36:55 +0200 Received: from is002254.saclay.cea.fr (is002254.saclay.cea.fr [132.166.134.67]) by muguet.saclay.cea.fr (8.12.2/8.12.2/CEAnet-Interne.1.0) with ESMTP id g5C7gvCf001088; Wed, 12 Jun 2002 09:42:57 +0200 (MEST) Received: from basile by is002254.saclay.cea.fr with local (Exim 3.35 #1 (Debian)) id 17I2la-00036j-00; Wed, 12 Jun 2002 09:42:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <15622.64332.518339.259345@is002254.saclay.cea.fr> Date: Wed, 12 Jun 2002 09:42:04 +0200 To: Xavier Leroy Cc: caml-list@inria.fr Subject: Re: [Caml-list] Unix.file_descr -> int ??? In-Reply-To: <20020611174527.A14450@pauillac.inria.fr> References: <20020611213158.A680@max.home> <20020611174527.A14450@pauillac.inria.fr> X-Mailer: VM 7.03 under Emacs 21.2.1 From: Basile STARYNKEVITCH Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>>>> "Xavier" == Xavier Leroy writes: [[citing Max Kirillov 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