Sean P. DeNigris wrote
As for #upToEnd
Dave, thanks for being so patient and generous with the explanations! I'm still a little confused about blocking and output. I'm exploring some of your suggestions from the last message, but one thing is bothering me... PipeableOSProcess>>#upToEnd eventually calls AttachableFileStream>>#upToEnd, which tries to perform a buffered read by "self nextInto: 1000" (which eventually calls primitiveFileRead which calls sqFileReadIntoAt which calls fread with count arg of 1000). I'm pretty sure this sets up a race condition. In http://forum.world.st/Standard-input-in-Pharo-td2173080.html#a4607687 , I found out that fread blocks forever under the following conditions: 1. there is less data available than was asked for 2. no EOF is encountered I think this is why it seems that my (and others') reports of hanging OSP images are inconsistent. If the process has generated at least 1000 characters output before the call to #upToEnd, or if (e.g. "p pipeFromOutput next: 10") less output is asked for than is available, there is no problem. But as soon as one more character is asked for than is available, the vm hangs in fread forever. I don't know what the solution is, but the current behavior doesn't seem workable. I'd be happy to work with you as much as I can to fix it... Thanks again. Sean -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4607761.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.