Rare project developers

[mc36 <>]

hi,

On 4/6/22 16:46, Alexander Gall wrote:
> > > > > > https://github.com/mc36/freeRouter/commit/106dc976b7604c1a45fb62dd3c0691da74e93f38
> > > > >
> > > > > Thanks. Why do we need the sleep(10)? It's pretty inconvenient.
> > > > so the idea here is that i did not wanted to keep track of the threads,
> > > > whereas ensuring a single exit point from the code... the ending of the
> > > > c code there only relays the stdio of the new process, and to be pretty
> > > > sure that the code exits at the first appearance of return status; that's
> > > > why i put it there... (an other option would be to use barriers, i know:))
> > >
> > > Maybe I'm missing something, but why don't you simply perform the
> > > wait() after exiting the loop? Then there would be no need to sleep
> > > and no need for the additional fork, I think.
>
> > so at that point, i exited the loop because select returned with hup,
> > i have good chances that the child already terminated so i cannot catch
> > the exit code....
>
> I think that's not correct. wait() also works if the child has already
> terminated.  From wait(2):
>
>    If a child has already changed state, then these calls return immediately
>
> And you should get the proper exit status in that case as well.

so if the man tells then it must be true, and really, it works this way so 
here we go:
https://github.com/mc36/freeRouter/commit/232fa5a0f0ce61b7499aaa968c02d120bb035107


> > that's why the new thread... regarding the sleep(10)
> > at the end, it's just a safety and but probably 10 is a bit overkill...
> > lemme reduce that to 1 too.... :)
>
> No sleep at all should be fine.

afterall, since we called for waitpid, yeahh, also true....
(but i just read this part of the mail so it'll be in a next commit...)

br,
cs