Sorry for sending this to both mail lists, but I figure until everyone has moved over to the new one at SourceForge I will post to both. We have created a TCL process that will augment the xref tables for Source Navigator. We want to do this so as to be able to cross-reference unique macro method invocations in our code base. As the process takes time we would like to run it in a separate process much the way dbimp runs, although we're using TCL to do this. Now for the problem, we can set up a pipe for hyper to run the TCL script and that seems to work (we use 'open', and the pipe seems to operate in both directions). We would like to use a pipe so that we can monitor progress and update a progress bar. The problem is that we can't find a way to know that the process has exited (to know when its done). The script has the TCL command 'exit 0' at the end. We've tried waiting for eof or for the pid to change, but it never does. We've tried sending back a unique string from the process so that the calling program can then just 'close' the pipe. The 'close' hangs. I'm also left with a hyper process still running in memory for any of these cases, so just not waiting and continuing on, eventually gets me when I try to exit Source Navigator. Can someone give me a suggestion on how to get this hyper process to end and a way to know that it has ended? Thanks. Bruce
Bruce,
[ This is a generic Unix programming issue, as you might already know. ]
It sounds like you're using a named pipe, which is the only way a pipe
could _appear_ to be bidirectional (pipes are fundamentally
unidirectional). Furthermore, you must be "open(2)"-ing the named pipe for
both read and write in the consumer process, That, if my guess is correct,
is the crux of your problem.
Pipes yield a persistent end-of-file condition when no process has the pipe
open for writing. If you open the file for reading only (O_RDONLY) in the
consumer process, then it will get and end-of-file indication (read will
continually return zero bytes read) as soon as the producer has closed its
end of the pipe (and after you've read any queued data).
By opening the named pipe in read/write mode (O_RDWR), you prevent this
end-of-file indication, because as far as the kernel knows, there's still a
process that might write to the pipe (in this case, the same process that's
reading from the pipe). This is a kind of weak deadlock condition. I say
"weak" because a non-ignored signal will interrupt the read and, if not
caught and not a "special" signal like SIGCLD or SIGSTOP, terminate the
process or, if caught, invoke the signal handler and lead to an EINTR
return from the read(2) call.
Just change the way your consumer process opens the file, and I believe
everything will work as you intend.
--
Randall Schulz
Mountain View, CA USA
At 08:47 2002-05-02, you wrote:
>Sorry for sending this to both mail lists, but I figure until everyone has
>moved over to the new one at SourceForge I will post to both.
>
>We have created a TCL process that will augment the xref tables for Source
>Navigator. We want to do this so as to be able to cross-reference unique
>macro method invocations in our code base. As the process takes time we
>would like to run it in a separate process much the way dbimp runs,
>although we're using TCL to do this. Now for the problem, we can set up
>a pipe for hyper to run the TCL script and that seems to work (we use
>'open', and the pipe seems to operate in both directions). We would like
>to use a pipe so that we can monitor progress and update a progress
>bar. The problem is that we can't find a way to know that the process has
>exited (to know when its done). The script has the TCL command 'exit 0'
>at the end. We've tried waiting for eof or for the pid to change, but it
>never does. We've tried sending back a unique string from the process so
>that the calling program can then just 'close' the pipe. The 'close'
>hangs. I'm also left with a hyper process still running in memory for any
>of these cases, so just not waiting and continuing on, eventually gets me
>when I try to exit Source Navigator. Can someone give me a suggestion on
>how to get this hyper process to end and a way to know that it has ended?
>
>Thanks.
>
>Bruce
Well, as further input, it appears that hyper is crashing upon exiting the tcl script I've asked it to run. Doesn't seem to matter whether I use r or r+ on the open statement. The tcl script I've created for test purposes, puts up a message box and then exits once I respond to the message box. I noticed that I could use 'puts' in the tcl script and its output went through the pipe to the parent app where it could be read with a 'gets'. This would work great for me. However, I get an error an additional error when hyper can't seem to exit that says 'can't write, channel file556 is not open'. Not sure if this is coming from the script in the spawned hyper process, or from hyper itself. The parent app does indeed receive everything the spawned tcl script sends with the 'puts'. The script ends with a 'exit 0'. This sure seems like a pretty simple task I'm trying to accomplish. Spawn a separate process to run a tcl script, get back occasional updates so I can update a progress bar, exit the process (and hyper) when the script is done, and then have the parent app remove the progress bar when it detects that the spawned process has ended/exited/closed. Is using hyper to run the tcl script process part of my problem? Is there a better way to do this? Any help would be greatly appreciated. Bruce -----Original Message----- From: Bruce Edson [mailto:bruce@steptech.com] Sent: Thursday, May 02, 2002 8:47 AM To: Sourcenav (E-mail); Sourcenav-Devl (E-mail) Subject: Running a separate TCL process using hyper Sorry for sending this to both mail lists, but I figure until everyone has moved over to the new one at SourceForge I will post to both. We have created a TCL process that will augment the xref tables for Source Navigator. We want to do this so as to be able to cross-reference unique macro method invocations in our code base. As the process takes time we would like to run it in a separate process much the way dbimp runs, although we're using TCL to do this. Now for the problem, we can set up a pipe for hyper to run the TCL script and that seems to work (we use 'open', and the pipe seems to operate in both directions). We would like to use a pipe so that we can monitor progress and update a progress bar. The problem is that we can't find a way to know that the process has exited (to know when its done). The script has the TCL command 'exit 0' at the end. We've tried waiting for eof or for the pid to change, but it never does. We've tried sending back a unique string from the process so that the calling program can then just 'close' the pipe. The 'close' hangs. I'm also left with a hyper process still running in memory for any of these cases, so just not waiting and continuing on, eventually gets me when I try to exit Source Navigator. Can someone give me a suggestion on how to get this hyper process to end and a way to know that it has ended? Thanks. Bruce