On 09 Jan 2015, at 10:55, squeak-dev-request@lists.squeakfoundation.org wrote:

Date: Fri, 9 Jan 2015 10:55:22 +0100 From: Henrik Johansen <henrik.s.johansen@veloxit.no mailto:henrik.s.johansen@veloxit.no> Subject: Re: [squeak-dev] Re: [Vm-dev] [OSProcess] forking and file descriptors

...

On 09 Jan 2015, at 10:44 , Max Leske <maxleske@gmail.com mailto:maxleske@gmail.com> wrote:

...

On 09 Jan 2015, at 10:25, vm-dev-request@lists.squeakfoundation.org mailto:vm-dev-request@lists.squeakfoundation.org <mailto: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 <mailto: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 <mailto: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?

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-no... 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: FD_CLOEXEC , the close-on-exec flag. If the FD_CLOEXEC bit is 0, the file descriptor will remain open across an execve(2) , otherwise it will be closed.

IIRC fork doesn’t use exec, so this flag doesn’t change anything for my scenario. [1] seems to confirm this.

Cheers, Max

[1] http://stackoverflow.com/questions/5713242/linux-fork-prevent-file-descripto...

Cheers, Henry