psa@otter.hple.hp.com (Patrick Arnold) (06/10/88)
I have a problem with emacs talking to subprocesses. I am working with a langauge which has texts made up of pieces of specifications interleaved with system commands such as compiler commands. The pieces of specification are inserted into a database by the subprocess and this runs fairly fast. However when the subprocess comes across a compile command it can spend a significant time (of the order of minutes) doing some compilation work. During this time emacs will still have text to send namely the stuff after the compile currently in progress. On some emacses this doesn't seem to create a problem but on others it does. What happens is that emacs will hang waiting for the process to read some more input. This seems to render emacs immune to anything apart from kill -9! On investigation it turns out that emacs can use several different ways of communicating with subprocesses depending on the system it is running on. These include pipes, ptys and sockets (to name but the few I found). Of course all these mechanisms have different buffering regimens. For example pipes are guaranteed to have 4096 on any unix but some may have more. I suppose sockets are constrained by available memory allocated to networking etc. This then is the explanation for the differing behaviours. On each system the ammount of text you need after the compile to hang emacs will depend on the method which emacs is using to communicate with its subprocesses. This isn't very pleasant. My question is whether anyone has encountered this problem before and found a generic solution (one which will behave the same on all systems) and which preferably hasn't got arbitrary restrictions (except perhaps no more filespace or virtual memory)? My only conclusion is that I will have to use temporary files and rewrite my subprocess to accept filenames of files to process asynchronously. I really don't relish the thought though! Patrick.