Process, anyone?

[Dar Scott]

On May 4, 2006, at 7:47 PM, Cal Horner wrote:

> A stand-alone app doesn't delete itself out of the Windows Task  
> Manager list
> when the stand-alone app is closed. The app remains in the  
> processes list
> and each time it is used another copy is left.

This might be an old, old Rev bug from before bugs were on bugzilla.   
I wrote the report below over four years ago.  I don't know if it  
applies now.  Also, I was a Newbie.  See #6.

Dar



I have some problems with "read from process."  I apologize for the  
missing detail.  I might be doing something silly that has caused  
some of these, but I think most are related to bugs.


1.  Delay time doesn't work how I expected

I open process "ping -n 10 127.0.0.1", read from the process until  
end and with a delay, then close.  I vary the delay.  I vary -n at  
times.  The -n switch controls the number of pings (and report lines)  
which are sent about a second apart.

The actual time (measured in ms, using milliseconds()) that the  
execution is in the read is less than the specified delay and can be  
a small fraction of the request.  This occurs even then the specified  
time is less than the ping time (process execution time).  The number  
of lines read seems to be roughly consistent with the time the  
execution is in the read, but not always.


2.  Read when no data at start hangs

A read (until end in 3000 milliseconds) from a process that does not  
generate output for a while at at start of the process hangs  
Revolution.  Revolution does not paint the content of windows.

This is contrasted with the tests in #1 above in which even a small  
amount of data read by the delay time will cause the read to complete.


3.  Immediate read without delay hangs

Read from process "ping -n 10 127.0.0.1" (until end, no delay) right  
after open hangs Revolution even though the process completes in 12  
seconds.  The window contents are painted in this case.


4.  ^. in "read from process" sometimes gets memory fault

I have gotten a memory fault in this situation but didn't write down  
details.

5.  Closing of error window from ^. in "read from process" gets fault

One time the runtime error window from ^. in "read from process"  
caused a memory fault when closed.  (Instruction at 0x004a6553,  
location at 4 could not be read)


6.  Process locks up (open, read, close)

Usually the ping process exits in tests in #1 above, even when the  
process is closed before or after the actual end of the function.   
However if -n 50 is used, and the process is closed much before the  
end of the pings, then the process hangs and will not exit.  It has  
to be killed.


(I can get ping data just fine with the shell function; I'm just  
trying to learn about "read from process" and the ping is handy.)