[squeak-dev] [Vm-dev] [OSProcess] forking and file descriptors
maxleske at gmail.com
Fri Jan 9 10:28:21 UTC 2015
> On 09 Jan 2015, at 10:55, squeak-dev-request at lists.squeakfoundation.org wrote:
> Date: Fri, 9 Jan 2015 10:55:22 +0100
> From: Henrik Johansen <henrik.s.johansen at veloxit.no <mailto:henrik.s.johansen at veloxit.no>>
> Subject: Re: [squeak-dev] Re: [Vm-dev] [OSProcess] forking and file
>> On 09 Jan 2015, at 10:44 , Max Leske <maxleske at gmail.com <mailto:maxleske at gmail.com>> wrote:
>>> On 09 Jan 2015, at 10:25, vm-dev-request at lists.squeakfoundation.org <mailto:vm-dev-request at lists.squeakfoundation.org> <mailto:vm-dev-request at lists.squeakfoundation.org <mailto: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> <mailto: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> <mailto: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.
> I was thinking you'd need to suspend the processes in the parent, before forking off a child, (to ensure there will be no possibility of a process running before it's suspended in the child) then resume after forking?
I’m hoping that I can get around that by using #valueUninterruptibly (or similar). It would be much nicer to leave the parent as it is and do everything related to the snapshot in the child. But maybe I’ll have to suspend the processes in the parent in the end.
>>> 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><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 :)
> It wouldn't be a branch of OSProcess, but an update to the platform SocketPlugin sources.
> I was probably wrong and it's not so new (wouldn't it be nice if all API's had the same structure as Postgres, where checking previous versions is *really* easy?), the 2004 version of the standard also includes it. A cursory check indicates at least OSX/*BSD/*Solaris would support it as well.
> Doing the equivalent on Windows seems to have certain caveats though...
> http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be-set-not-inheritable <http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be-set-not-inheritable>
I’m not entirely sure that what you are suggesting will work, at least not with FD_CLOEXEC. man fcntl says:
File descriptor flags
The following commands manipulate the flags associated with a file
descriptor. Currently, only one such flag is defined:
the close-on-exec flag. If the
bit is 0, the file
descriptor will remain open across an
, otherwise it will be
IIRC fork doesn’t use exec, so this flag doesn’t change anything for my scenario.  seems to confirm this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev