Wait for fork/exec

10 views
Skip to first unread message

JR

unread,
Mar 13, 2018, 11:35:13 AM3/13/18
to fluxcapacitor development
Hi,

I am trying to use fluxcapacitor to speed up a bunch of processes.
But a common problem is that the parent process starts a child and waits some
time for a connection from the child. It seems like fluxcapacitor thinks all processes
are waiting for a timeout and speeds up the time. The parent process gets a timeout
while waiting for the connection before the child even enters main().

Should this setup work? I can try to debug it, if it is supposed to work.

Best regards,
   Jörg

Marek Majkowski

unread,
Mar 13, 2018, 11:41:29 AM3/13/18
to joerg....@pdv-fs.de, fluxcapacitor development
Hi,

This is indeed a common pattern, but fluxcapacitor just shows the
obvious race condition.

Instead you should do a proper "wait", that is, for example perform a
blocking read from child socket, and perform a flushed "write" from a
child once socket is set up.

Another option is to perform this synchronization with signals, but
frankly speaking I'm not sure if that will work. It should.

I used to do "wait" after fork in tests myself, but this is just
buggy. Nowadays I mostly do the stdout trick. Once again:

parent:

p = fork_and_exec(child)
port_number = p.stdout.read() # blocking wait on stdout of child
socket.connect("127.0.0.1", port_number) #-> tcp socket from child is ready!

child:

s = socket
s.bind()
s.listen()
print s.getsockname()
for {
s.accept()
}


Does it make sense?
> --
> You received this message because you are subscribed to the Google Groups
> "fluxcapacitor development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fluxcapacitor-...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

JR

unread,
Mar 13, 2018, 11:52:55 AM3/13/18
to fluxcapacitor development
Hi,

Thanks for your suggestions. I understand your fix, but I think this is too cumbersome for my setup.
My thoughts are along this lines: It is possible to capture the fork with ptrace. Assume this new process
is doing work until it enters some blocking functions. This will prevent fluxcapacitor from speeding up the
time while exec and the dynamic loader are still running.

I hope this makes sense.

- Jörg

Marek Majkowski

unread,
Mar 13, 2018, 11:58:33 AM3/13/18
to joerg....@pdv-fs.de, fluxcapacitor development
On 13 March 2018 at 16:52, JR <joerg....@pdv-fs.de> wrote:
> Hi,
>
> Thanks for your suggestions. I understand your fix, but I think this is too
> cumbersome for my setup.
> My thoughts are along this lines: It is possible to capture the fork with
> ptrace. Assume this new process
> is doing work until it enters some blocking functions. This will prevent
> fluxcapacitor from speeding up the
> time while exec and the dynamic loader are still running.
>
> I hope this makes sense.

There are a number of hacks already in place to do these kind of things.
a) we try to pin all the processes (and children, since the taskset
thing should be inherited) to one cpu to make everything serialized.
b) we "speed up time" only after we checked all the pids are in "S"
state in the /proc/pid/state

The point is - why the child process would be in "S" state during
startup? It should be "R" running.

In any case - we can totally add another hack preventing "speedup"
when a forked process is new. Not sure how effective that would be
though.
Reply all
Reply to author
Forward
0 new messages