public inbox for
 help / color / mirror / Atom feed
From: Randall R Schulz <>
To: Bruce Edson <>,,
Subject: Re: Running a separate TCL process using hyper
Date: Thu, 02 May 2002 09:06:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <26F9F6EAB586D411850700B0D049E6E4014D2FCD@shasta.pdx.stepte>


[ 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?

       reply	other threads:[~2002-05-02 16:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <26F9F6EAB586D411850700B0D049E6E4014D2FCD@shasta.pdx.stepte>
2002-05-02  9:06 ` Randall R Schulz [this message]
2002-05-02 13:00 Bruce Edson
  -- strict thread matches above, loose matches on Subject: below --
2002-05-02  8:48 Bruce Edson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).