Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.perl
Subject: Re: perl compared to other Unix tools
Message-ID: <15024:Dec1322:59:4090@kramden.acf.nyu.edu>
Date: 13 Dec 90 22:59:40 GMT
References: <9592:Dec920:40:5190@kramden.acf.nyu.edu> <110275@convex.convex.com> <1990Dec12.010203.18075@NCoast.ORG>
Organization: IR
Lines: 27

In article <1990Dec12.010203.18075@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes:
> As quoted from <110275@convex.convex.com> by tchrist@convex.COM (Tom Christiansen):
> | In article <9592:Dec920:40:5190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> | >2. Pass descriptors back and forth between programs. This is hellishly
> | I'm not sure what you want here.  It's pretty easy in perl to 
> | connect processes through a file descriptor:	
> I think he means ioctl(streamfd, I_SENDFD, fd) or the socket equivalent.

Yes. I seem to have this huge pile of secure resource managers, all of
which create a descriptor pointing to a secure resource, then fork off a
child process with access to that descriptor. In the latest program I
tried an option for passing the descriptor up to another process, which
would take control. You can't imagine how much better life would be if
there were a standard protocol and library routine for this job.

Add non-preemptive threads to this message-passing language, and it
would finally be conceivable that UNIX system resources be implemented
in---and used by---Perl.

> Problem is, I use plenty of machines that *don't* support it.  This is about
> as portable as that alarm() replacement that uses setitimer...  less so, in
> fact, as SVR3 with Streams support has I_SENDFD.

Uh, other way around? SVR3 with Streams does indeed have I_SENDFD, which
is why descriptor passing *is* so portable.

---Dan