[squeak-dev] Re: [Vm-dev] [OSProcess] forking and file descriptors
maxleske at gmail.com
Fri Jan 9 09:44:46 UTC 2015
> On 09 Jan 2015, at 10:25, vm-dev-request at lists.squeakfoundation.org wrote:
> Date: Fri, 9 Jan 2015 10:24:42 +0100
> From: Henrik Johansen <henrik.s.johansen at veloxit.no <mailto:henrik.s.johansen at veloxit.no>>
> Subject: Re: [squeak-dev] [Vm-dev] [OSProcess] forking and file
>> On 09 Jan 2015, at 9:32 , Max Leske <maxleske at gmail.com <mailto:maxleske at gmail.com>> wrote:
>> That would mean that I must not close any sockets in the child. One option, it seems to me, is to suspend all processes that use sockets. Terminating them might pose another problem, if socket destruction is part of an unwind block in one of the processes (e.g. TCP connections in Seaside) then sockets will be destroyed during termination.
>> Another option: set all the socket handles to nil, then terminate the processes (yes ugly, but it might just work…).
> Just beware you might run into the issue that resuming a processes waiting for a semaphore will proceed as if the semaphore were signalled,
> Can't tell offhand if that would actually be a problem in this case, or if the affected processes would promptly resume waiting after socket read/writes may initiate with no data.
I wouldn’t resume any of those processes if I can help it. After creating the segment the child kills itself. Thanks for pointing that out though.
> Another (probably non-portable, which would be painful if not consistent across platforms) option:
> Forget about image-side handling, and alter the SocketPlugin to set FD_CLOEXEC if available when opening sockets. (It's in http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html> , but that's rather new)
> On newer Linuxen, you also have SOCK_CLOEXEC for socket(), which opens/sets in an atomic operation, but the race condition avoided by that is hardly relevant in our case.
True. But I really don’t want to maintain a branch of OSProcess :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev