Daniel Eischen wrote: >On Mon, 23 Jan 2006, Julian Elischer wrote: > > > >>Robert Watson wrote: >> >> >>well, the operation woudll continue for the parent only I woudl assume. >> >> >> >>>(although davidxu is changing that) >>> >>> >>I'm not convinced that that multiple threads should be allowed to >>proceed during a fork >>but I can see that not allowing it is more a "foot shooting avoidance" >>than a requirement. >>it could be allowed that if you do a fork and allow multipel threads to >>runat the same time >>and end up with an inconsistant address space in the child, then you get >>what you deserve. >>:-) >> >> > >POSIX specifies that only 1 thread (the forking thread) is present >after a fork. If you want all (or some subset) of the parent's >threads to exist after a fork(), you must call it something >else (use a flag to rfork?) and ensure it is not the default >behavior. > > I'm not saying the others would survive, but that if they are running on other processors at the moment when we duplicate the address space, we may get a rather inconsistent address space.. The current code handles this by forcing all other threads into a suspended state before allowing the fork() to proceeed and then allowing them to continue (on the parent only) when the fork has completed. There aer some cases when this behaviour has been seen to cause problems and it has been suggested that this is not a requirement.Received on Tue Jan 24 2006 - 01:30:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC