🚀 go-pugleaf

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