From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8075 invoked by alias); 2 May 2002 16:06:56 -0000 Mailing-List: contact sourcenav-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sourcenav-owner@sources.redhat.com Received: (qmail 8054 invoked from network); 2 May 2002 16:06:54 -0000 Received: from unknown (HELO darius.concentric.net) (207.155.198.79) by sources.redhat.com with SMTP; 2 May 2002 16:06:54 -0000 Received: from newman.concentric.net (newman.concentric.net [207.155.198.71]) by darius.concentric.net [Concentric SMTP Routing 1.0] id g42G4LO15238 ; Thu, 2 May 2002 12:04:35 -0400 (EDT) Received: from Clemens.cris.com (da003d1357.sjc-ca.osd.concentric.net [64.1.5.78]) by newman.concentric.net (8.9.1a) id MAA18164; Thu, 2 May 2002 12:03:50 -0400 (EDT) Message-Id: <5.1.0.14.2.20020502085510.00b01538@pop3.cris.com> X-Sender: rrschulz@pop3.cris.com Date: Thu, 02 May 2002 09:06:00 -0000 To: Bruce Edson , sourcenav@sources.redhat.com, sourcenav-devl-request@lists.sourceforge.net From: Randall R Schulz Subject: Re: Running a separate TCL process using hyper In-Reply-To: <26F9F6EAB586D411850700B0D049E6E4014D2FCD@shasta.pdx.stepte ch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SW-Source: 2002-q2/txt/msg00037.txt.bz2 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