[Pharo-project] OSProcess - is process done?
Sometimes, OSProcess hangs even though the underlying command has completed. For example, on Mac 10.7.3: p := PipeableOSProcess waitForCommand: 'ps -ax -o pid,command' "never returns" even though "p upToEnd" immediately returns the output if I use #command: instead of waiting. How best to handle this? Thanks. Sean -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4569088.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Wed, Apr 18, 2012 at 02:47:38PM -0700, Sean P. DeNigris wrote:
Sometimes, OSProcess hangs even though the underlying command has completed.
For example, on Mac 10.7.3: p := PipeableOSProcess waitForCommand: 'ps -ax -o pid,command' "never returns" even though "p upToEnd" immediately returns the output if I use #command: instead of waiting.
How best to handle this?
Thanks. Sean
PipeableOSProcess class>>waitForCommand: is just a loop that waits for the command (running in an external process) to complete. If the command does not complete, it keeps looping. The program that you are running (/bin/ps) will try to exit after it has written all of its output to its standard output, which in this case is a pipe connected back to your VM. But if the pipe fills up (the operating system will put some limit on this), the /bin/ps program will block trying to write to its output until somebody reads some of that data from the pipe. If nobody reads the output, the /bin/ps program will just block forever, and it will seem to be "stuck" and will never exit. What to do? Read the data from the output of the PipeableOSProcess. The /bin/ps program will then be unblocked, and it will finish writing its output and then exit normally. Dave
Hi. I use OSProcess in Windows (XP and Seven) and I notice that it hang when I open the image with OSProcess already loaded. I try in Seaside-3.0.7-OneClick and Pharo-1.4-14438-OneClick, and I get same error. Step to reproduce: 1. Load OSProcess in a clean image. I use this snippet: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOSProcess'; load. ((Smalltalk at: #ConfigurationOfOSProcess) project version: #stable) load. 2. Save and quit. 3. Open same image, with OSProcess already load. 4. Inspect this: OSProcess command: 'dir'. You can notice that process never is completed, however the operating system window where running is already closed. If you inspect previous code after step 1 (before save and quit) the process is completed. In another hand, I notice that in the ConfigurationOfOSProcess>>baseline44 there is a OSProcess-Tests package, but this there isn't in the repo, and the tests classes are loaded with just load OSProcess package. I don't want load the tests in the deploy images. Maybe I do something wrong. Regards. El 18 de abril de 2012 21:07, David T. Lewis <lewis@mail.msen.com> escribió:
On Wed, Apr 18, 2012 at 02:47:38PM -0700, Sean P. DeNigris wrote:
Sometimes, OSProcess hangs even though the underlying command has completed.
For example, on Mac 10.7.3: p := PipeableOSProcess waitForCommand: 'ps -ax -o pid,command' "never returns" even though "p upToEnd" immediately returns the output if I use #command: instead of waiting.
How best to handle this?
Thanks. Sean
PipeableOSProcess class>>waitForCommand: is just a loop that waits for the command (running in an external process) to complete. If the command does not complete, it keeps looping.
The program that you are running (/bin/ps) will try to exit after it has written all of its output to its standard output, which in this case is a pipe connected back to your VM. But if the pipe fills up (the operating system will put some limit on this), the /bin/ps program will block trying to write to its output until somebody reads some of that data from the pipe. If nobody reads the output, the /bin/ps program will just block forever, and it will seem to be "stuck" and will never exit.
What to do? Read the data from the output of the PipeableOSProcess. The /bin/ps program will then be unblocked, and it will finish writing its output and then exit normally.
Dave
Forget to say something, if I unload and reload the OSProcess package, then starts working well again. El 19 de abril de 2012 09:27, Gastón Dall' Oglio <gaston.dalloglio@gmail.com
escribió:
Hi.
I use OSProcess in Windows (XP and Seven) and I notice that it hang when I open the image with OSProcess already loaded. I try in Seaside-3.0.7-OneClick and Pharo-1.4-14438-OneClick, and I get same error.
Step to reproduce: 1. Load OSProcess in a clean image. I use this snippet: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOSProcess'; load. ((Smalltalk at: #ConfigurationOfOSProcess) project version: #stable) load.
2. Save and quit. 3. Open same image, with OSProcess already load. 4. Inspect this: OSProcess command: 'dir'.
You can notice that process never is completed, however the operating system window where running is already closed. If you inspect previous code after step 1 (before save and quit) the process is completed.
In another hand, I notice that in the ConfigurationOfOSProcess>>baseline44 there is a OSProcess-Tests package, but this there isn't in the repo, and the tests classes are loaded with just load OSProcess package. I don't want load the tests in the deploy images. Maybe I do something wrong.
Regards.
El 18 de abril de 2012 21:07, David T. Lewis <lewis@mail.msen.com>escribió:
On Wed, Apr 18, 2012 at 02:47:38PM -0700, Sean P. DeNigris wrote:
Sometimes, OSProcess hangs even though the underlying command has completed.
For example, on Mac 10.7.3: p := PipeableOSProcess waitForCommand: 'ps -ax -o pid,command' "never returns" even though "p upToEnd" immediately returns the output if I use #command: instead of waiting.
How best to handle this?
Thanks. Sean
PipeableOSProcess class>>waitForCommand: is just a loop that waits for the command (running in an external process) to complete. If the command does not complete, it keeps looping.
The program that you are running (/bin/ps) will try to exit after it has written all of its output to its standard output, which in this case is a pipe connected back to your VM. But if the pipe fills up (the operating system will put some limit on this), the /bin/ps program will block trying to write to its output until somebody reads some of that data from the pipe. If nobody reads the output, the /bin/ps program will just block forever, and it will seem to be "stuck" and will never exit.
What to do? Read the data from the output of the PipeableOSProcess. The /bin/ps program will then be unblocked, and it will finish writing its output and then exit normally.
Dave
David T. Lewis wrote
PipeableOSProcess class>>waitForCommand: is just a loop...
David, It doesn't seem like that's the problem because it's intermittent. I can run the exact same command with the same output and sometimes it recognizes that it's complete and sometimes not. I don't know if it's related, but when I do: p := PipeableOSProcess command: '/usr/bin/expect /path/to/expect.exp'. where expect.exp is a wrapper to supply login credentials to ssh, I get a similar problem... p next: 100. "This returns the welcome text from the server... ssh has successfully connected" p nextPutAll: 'ls', Character cr asString. "I send the ls command to the remote server" p atEnd. "Primitive failed <primitive: 'primitiveFileSetPosition' module: 'FilePlugin'> in AttachableFileStream(StandardFileStream)>>primSetPosition:to:" "weird, no?" p upToEnd. "This hangs, even though there is output in the pipe" p next: 5. "In fact, if I get the output a little at a time, I can see the result of the ls command" What do you think? Thanks. Sean -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4575379.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sean P. DeNigris wrote
p upToEnd. "This hangs, even though there is output in the pipe"
I debugged this with the Stack VM from Jenkins. It's hanging in sqFileBasicPluginPrims.c on line 360: bytesRead = fread(dst, 1, count, file); This line seems to never return, although the docs suggest that it should just return an error or less data if the requested data is not available. HTH, Sean -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4587479.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 25 April 2012 19:48, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
p upToEnd. "This hangs, even though there is output in the pipe"
I debugged this with the Stack VM from Jenkins. It's hanging in sqFileBasicPluginPrims.c on line 360: Â bytesRead = fread(dst, 1, count, file);
This line seems to never return, although the docs suggest that it should just return an error or less data if the requested data is not available.
fread is just a thin wrapper around read() call. it blocks the caller upon completing an operation. you can set a file handle to non-blocking mode using fcntl() call with O_NONBLOCK flag. Which i think is a first and foremost thing which VM should do to prevent blocking like that :)
HTH, Sean
-- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4587479.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Here's the OSProcess test results: * Pharo 1.3 * Mac Lion 10.7.3 * recent Cog VM from the Pharo CI server * latest version of OSProcess (the all-in-one package, not the broken up ones) 192 run, 110 passes, 0 expected failures, 79 failures, 3 errors, 0 unexpected passes Is that what you would expect?! 3 errors: #('AioEventHandlerTestCase>>#testPrimAioModuleName' 'UnixProcessAccessorTestCase>>#testDupTo' 'UnixProcessTestCase>>#testEightLeafSqueakTree') 79 failures: #('AioEventHandlerTestCase>>#testEnableHandleAndDisable' 'AioEventHandlerTestCase>>#testFileReadableEvent' 'AioEventHandlerTestCase>>#testFileWritableEvent' 'AioEventHandlerTestCase>>#testHandleForFile' 'AioEventHandlerTestCase>>#testHandleForSocket' 'AioEventHandlerTestCase>>#testPrimAioModuleVersionString' 'AioEventHandlerTestCase>>#testSocketReadableEvent' 'AioEventHandlerTestCase>>#testSuspendAioForSocketReadableEvent' 'UnixProcessAccessorTestCase>>#testRedirectStdOutTo' 'UnixProcessTestCase>>#testCatAFile' 'UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDo' 'UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDoThenQuit' 'UnixProcessTestCase>>#testClassForkSqueak' 'UnixProcessTestCase>>#testClassForkSqueakAndDo' 'UnixProcessTestCase>>#testClassForkSqueakAndDoThenQuit' 'UnixProcessTestCase>>#testForkHeadlessSqueakAndDo' 'UnixProcessTestCase>>#testForkHeadlessSqueakAndDoThenQuit' 'UnixProcessTestCase>>#testForkSqueak' 'UnixProcessTestCase>>#testForkSqueakAndDo' 'UnixProcessTestCase>>#testForkSqueakAndDoThenQuit' 'UnixProcessTestCase>>#testHeadlessChild' 'UnixProcessTestCase>>#testRunCommand' 'UnixProcessTestCase>>#testSpawnTenHeadlessChildren' 'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses01' 'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses02' 'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses03' 'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses04' 'UnixProcessUnixFileLockingTestCase>>#testCooperatingProcesses05' 'UnixProcessUnixFileLockingTestCase>>#testFailFileLockOnLockedFile' 'UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedOverlappedRegion' 'UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedRegion' 'UnixProcessUnixFileLockingTestCase>>#testFailLockOnLockedSupersetRegion' 'UnixProcessUnixFileLockingTestCase>>#testFailRegionLockOnLockedFile' 'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite01' 'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite02' 'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite03' 'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite04' 'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite05' 'UnixProcessUnixFileLockingTestCase>>#testLockEntireFileForWrite06' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead01' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForRead02' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite01' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite02' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite03' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite04' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite05' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite06' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite07' 'UnixProcessUnixFileLockingTestCase>>#testLockRegionForWrite08' 'UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions' 'UnixProcessUnixFileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion' 'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses01' 'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses02' 'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses03' 'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses04' 'UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses05' 'UnixProcessWin32FileLockingTestCase>>#testFailFileLockOnLockedFile' 'UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedOverlappedRegion' 'UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedRegion' 'UnixProcessWin32FileLockingTestCase>>#testFailLockOnLockedSupersetRegion' 'UnixProcessWin32FileLockingTestCase>>#testFailRegionLockOnLockedFile' 'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite01' 'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite02' 'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite03' 'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite04' 'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite05' 'UnixProcessWin32FileLockingTestCase>>#testLockEntireFileForWrite06' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead01' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForRead02' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite01' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite02' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite03' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite04' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite05' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite06' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite07' 'UnixProcessWin32FileLockingTestCase>>#testLockRegionForWrite08' 'UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnAdjacentLockedRegions' 'UnixProcessWin32FileLockingTestCase>>#testNoFailLockOnDifferentLockedRegion') -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4575406.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (4)
-
David T. Lewis -
Gastón Dall' Oglio -
Igor Stasenko -
Sean P. DeNigris