Unix Programming - Rendezvous between related processes

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > June 2004 > Rendezvous between related processes





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Rendezvous between related processes
Olivier Parisy

2004-06-26, 10:11 am

Hi all,

I have three related processes, A, B and C : A forks B which then forks C.
Each of them set up some communication pipes, then execute some specific code.

It seems like sometimes, I meet a race condition where some processes start
reading before others had time to properly set up theirs ends of pipes.

What I'd like to do is to implement some kind of rendezvous mecanism where all
three processes would have to wait at at given points (after pipes setup)
until they all have reached it.

I know this is a classical CS exercice, but I fail in designing it. Because
these are related processes, I thought about using an inherited semaphore. Is
this a proper approach ? Or perhaps, a shared, protected counter ?

Any advice on the more canonical way to implement this would be very
appreciated !

Best regards,
Olivier Parisy.
Olivier Parisy

2004-06-26, 10:11 am

Pascal Bourguignon wrote:
> olivier.parisy@free.fr (Olivier Parisy) writes:
>
[vbcol=seagreen]
> Set up the ends of pipes BEFORE forking!


It would be best, but I don't see how I can do this. I use dup2()
to redirect stdin and/or stdout to the proper pipes ; so this
setting will change for each process.

But perhaps you mean I should setup pipes properly in father
processes (only issuing dup2(), without closing unneeded ends)
before forking, and then adjust things in children processes
after forking ?

I will think about this !

Thanks,
Olivier Parisy.
Barry Margolin

2004-06-26, 10:11 am

In article <40dad0fa$0$29364$626a14ce@news.free.fr>,
Olivier Parisy <olivier.parisy@free.fr> wrote:

> Pascal Bourguignon wrote:
>
>
> It would be best, but I don't see how I can do this. I use dup2()
> to redirect stdin and/or stdout to the proper pipes ; so this
> setting will change for each process.
>
> But perhaps you mean I should setup pipes properly in father
> processes (only issuing dup2(), without closing unneeded ends)
> before forking, and then adjust things in children processes
> after forking ?


It shouldn't matter when you do the dup2's.

What do you mean by "properly set up theirs ends of pipes"? Once you
create the pipe, there's no special setup required.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Olivier Parisy

2004-06-26, 10:11 am

Olivier Parisy wrote:

> Pascal Bourguignon wrote:
[vbcol=seagreen]
> But perhaps you mean I should setup pipes properly in father
> processes (only issuing dup2(), without closing unneeded ends)
> before forking, and then adjust things in children processes
> after forking ?


That worked fine ! Thank you very much !

Regards,
Olivier Parisy.
Olivier Parisy

2004-06-26, 10:11 am

Barry Margolin wrote:

> It shouldn't matter when you do the dup2's.


Is that so ? So, if a process starts reading on a pipe
whose other end isn't connected to the standard output
of a subprocess, it should just block, and not get an EOF ?

And, after the dup2() is performed, reading should resume
properly ? Then I may have fixed my problem as a side effect
of another bug pinning :-)

> What do you mean by "properly set up theirs ends of pipes"? Once you
> create the pipe, there's no special setup required.


I just mean "to use dup2() so that they can be read or written
to using standard IO". Would I read/write directly to the proper
descriptors, no setup would be necessary, indeed.

Regards,
Olivier Parisy.

Eric Sosman

2004-06-26, 10:11 am

Olivier Parisy wrote:
> Barry Margolin wrote:
>
>
>
> Is that so ? So, if a process starts reading on a pipe
> whose other end isn't connected to the standard output
> of a subprocess, it should just block, and not get an EOF ?


Exactly.

> And, after the dup2() is performed, reading should resume
> properly ?


The dup2() really has nothing to do with what the read()
sees. The read() will wait until somebody does a write(),
and it doesn't matter what file descriptor number is used
for the write(). You could call dup2() ninety-nine times
and give yourself a hundred file descriptors all open on
the writing end of the pipe; the read() will receive anything
you write() to any of them.

> Then I may have fixed my problem as a side effect
> of another bug pinning :-)
>
>
>
> I just mean "to use dup2() so that they can be read or written
> to using standard IO". Would I read/write directly to the proper
> descriptors, no setup would be necessary, indeed.


--
Eric.Sosman@sun.com

David Schwartz

2004-06-26, 10:11 am


"Olivier Parisy" <olivier.parisy@free.fr> wrote in message
news:40dad0fa$0$29364$626a14ce@news.free.fr...

> But perhaps you mean I should setup pipes properly in father
> processes (only issuing dup2(), without closing unneeded ends)
> before forking, and then adjust things in children processes
> after forking ?


Exactly.

> I will think about this !


Also, think about having the parent wait until the child tells it that
it is ready (over the pipe, of course).

DS


Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com