🚀 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

I write:

>     It's possible this belongs on one of the UNIX groups, but it
>touches on some NeXT stuff so I thought I'd try here first. I'm in
>the midst of doing an App that uses Allegro for some NLP stuff. I'm
>spawning a cl process and making its stdin one end of a pipe, and its
>stdout another end of a pipe like this:
>
>if((pid = fork()) == 0) {
>	fclose(stdin);
>	dup(cl_stdin);
>	fclose(stdout);
>	dup(cl_stdout);
>	execl(...);
>	}
>
>     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.)
>

I got loads of great responses for this. Thanks! Just to save time and
bandwidth I figured I'd summarize.

Basically there are two facilities for doing this. The first is a vanilla
BSD routine called select(2). The second is a NeXTstep specific called
DPScallFD(). Alternatively there is a NeXTstep example called Subprocess
which does all this for you. Guess which I'll use :)

-Chris

In article <1992Apr7.170318.19742@noose.ecn.purdue.edu>  
songer@ei.ecn.purdue.edu (Christopher M Songer) writes:
> Hi!
>      It's possible this belongs on one of the UNIX groups, but it
> touches on some NeXT stuff so I thought I'd try here first. I'm in
> the midst of doing an App that uses Allegro for some NLP stuff. I'm
> spawning a cl process and making its stdin one end of a pipe, and its
> stdout another end of a pipe like this:
> 
> if((pid = fork()) == 0) {
> 	fclose(stdin);
> 	dup(cl_stdin);
> 	fclose(stdout);
> 	dup(cl_stdout);
> 	execl(...);
> 	}
> 
>      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.)
> 
>      One thing I've considered is using a thread with a realtively
> low priority to watch the file descriptor and buffer what comes through.
> Once we have a complete response from Lisp, send a message (or put an
> event in the Event Queue???) to process it. But I'm not sure that it
> is safe to use an objc messge from a thread and I'm not sure how to
> put an event in the event queue. I don't really want to have to subclass
> Application if I can help it.
> 
>      Anyway, suggestions on how to handle this are more then apprecaited.
> Thanks!
> -Chris
> songer@ecn.purdue.edu
> chris%broadsword.UUCP@ecn.purdue.edu

A very good solution to this problem is contained in  
/NextDevelopers/Examples/Subprocess.  It does exactly what you want and uses  
DPSAddFD() to tie into the stdin/stdout of the subprocess.  I have modified  
this further to separate the stdout from stderr (the Subprocess object blends  
them together), allow pausing and resuming the process and some other neat-o's.

--
+--------------------------------+------------------------------------------+
|        Drew  Davidson          | "Whining is anger coming through a small |
|         Software Guy           |  opening."                               |
| First National Bank of Chicago |            - Stuart Smalley              |
|     drew@fnbc.com  (NeXTmail)  |              Caring Nurturer             |
+--------------------------------+------------------------------------------+