> Hi Lee,
>
>> I have yet to find any documentation on the web that defines the order
>> of return.
>
> The order of return after fork(2) is defined as being not determinable,
> i.e. correct code has to cope with either order or even simultaneous
> return since another CPU might be brought it to run one of them.
>
> With Linux 2.2 and 2.4 the parent returned first, with 2.6 it's the
> child up until 2.6.32 when it switched once again. Other Unix operating
> systems may not even be consistent within a version.
>
> vfork(2)'s raison d'être meant the parent didn't run until the child was
> finished or overwritten with execve(2). Nowadays, that's not true and
> can't be assumed.
>
> Cheers, Ralph.
Thanks Ralph, that does make things clearer. It seems that UnixLib is
not technically wrong and it will still fail for some programs even
if changed.
Swapping the parent and child in the example does make it work, so I
think the best solution is for any package that is dependant on the
parent returning first to be altered to comply with UnixLib where
possible. Hopefully, this is a rare problem.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment