🚀 go-pugleaf

In article <1992Apr7.170318.19742@noose.ecn.purdue.edu>  
songer@ei.ecn.purdue.edu (Christopher M Songer) writes:
> 
>      Here's my problem. Common Lisp can respond to commands in its
> own sweet time. I don't want to sit around polling on the file
> descriptor all the time. This would hose the user interface. What
> I want to happen is this:
> 
>      When the OS detects something to be read on the descriptor it
> wakes up a thread (or whatever) and the thread takes care of all my I/O.
> I think maybe the SIGIO signal sort of does this -- but it seems  
awefully
> crufty to me. (Not thread based at all, and who wants to poll ALL the
> possible descriptors.)

What you probably want to do here is to use the DPS function DPSAddFD.  If  
you pass this function a file descriptor, the Application will monitor the  
file descriptor for you.  You will get a callback whenever there is  
activity on the descriptor.
Check out the description of DPSAddFD in DL.

HOWEVER...

It sounds like you may be re-inventing the wheel here.  There is already  
some great example code which does all this grungy stuff for you.
The Subprocess example in /NextDeveloper/Examples is an example of how to  
launch a UNIX subprocess and communicate with it from a NeXTstep app.
It contains a Subprocess object, to which you send the UNIX command to be  
launched.  It handles all the nasty unix stuff for you, including  
asynchronous communication, pty support, etc., etc.

You may want to use this object instead of re-creating it yourself from  
scratch.

-- josh