Subject: [clisp-list] why dup() is portability-challenged

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Tue Jun 10 07:53:01 2003

Hi,

Sam Steingold answered to Arseny Slobodjuck:
>> execxyz gives no way to redirect streams on windows, that's 
>why we use
>> CreateProcess (I think) and bearing with quoting.
>I see.  this boils down to the effective absence of dup2() on woe32.

This is a note of mine to mention that dup() is misdesigned from a portability point of view. It should not form a model for higher-level functionality in Lisp.

On some systems, notably non-UNIX ones, there's a coupling between access and locking. I consider that a good thing.

UNIX (and esp. NFS) historically does not, and that's why we've seen lots of portability problems with sendmail, uucp and related programs, which have to choose among many different (sometimes buggy) incompatible implementations of file locking (ever seen foo.LOCK files here and there?).

On AmigaOS (and maybe also MS-Windows), coupling is the default, in conjunction with a multiple-readers, single writer model (well known from e.g. simple databases like MySQL). That works very well in many many situations.

On such systems, you cannot dup a single-writer (exclusive access) resource - quite obviously. You would obtain two writers to the unique resource, which is forbidded by contract.

On such systems, you have means (e.g. a protocol) to pass resources from one process to another. But the resource is still unique.

On UNIX, you can "cat > /tmp/foocat" at the same time in several shells, and use intermittent "cat /tmp/foocat" from a third shell to witness how the different programs happily overwrite part of the other program's data. An interesting UNIX experience I highly recommend.

On UNIX, dup() is almost a necessity in the presence of fork().

The model and implementation of UNIX pipes, given the presence of dup() and fork(), is certainly interesting. UNIX pipes are probably not referentially transparent as in functional programming.

>could you please find out how cygwin implements dup2?
That *may* not help, since the cygwin runtime environment may do things behind the scenes, even after an application closes, that an application can not. OTOH, it may show how to master that aspect of MS-Woes.

The cygwin environment may simulate dup() by simply serialiazing access via dup()'ed file descriptors to the unique MS-Windows file resource across all cygwin-using programs. The CLISP application cannot do that, only the cygwin OS emulation environment can.
It could be like this, it must not.

Regards,
	Jorg Hohle.

---

From: Arseny Slobodjuck <[email-masked]>
Date: Wed Jun 11 04:03:12 2003

Hi,

Wednesday, June 11, 2003, 12:51:45 AM, you wrote:

> On  UNIX,  you  can  "cat > /tmp/foocat" at the same time in several
> shells, and use intermittent "cat /tmp/foocat" from a third shell to
> witness  how  the  different  programs happily overwrite part of the
> other  program's  data.  An  interesting  UNIX  experience  I highly
> recommend.

Your essay is very in time because I'm just figuring out why two
sequential "launch > foo" don't work on unix as I expect, thank you!

-- 
Best regards,
 Arseny