On 09 Jan 2015, at 10:25, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Fri, 9 Jan 2015 10:24:42 +0100 From: Henrik Johansen <henrik.s.johansen@veloxit.no mailto:henrik.s.johansen@veloxit.no> Subject: Re: [squeak-dev] [Vm-dev] [OSProcess] forking and file descriptors
On 09 Jan 2015, at 9:32 , Max Leske <maxleske@gmail.com mailto:maxleske@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 :)
Cheers, Henry
On 09 Jan 2015, at 10:44 , Max Leske maxleske@gmail.com wrote:
On 09 Jan 2015, at 10:25, vm-dev-request@lists.squeakfoundation.org mailto:vm-dev-request@lists.squeakfoundation.org wrote:
Date: Fri, 9 Jan 2015 10:24:42 +0100 From: Henrik Johansen <henrik.s.johansen@veloxit.no mailto:henrik.s.johansen@veloxit.no> Subject: Re: [squeak-dev] [Vm-dev] [OSProcess] forking and file descriptors
On 09 Jan 2015, at 9:32 , Max Leske <maxleske@gmail.com mailto:maxleske@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?
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 :)
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-no...
Cheers, Henry
vm-dev@lists.squeakfoundation.org
-
Henrik Johansen -
Max Leske