Re: [Vm-dev] [OSProcess] forking and file descriptors
Locked
 
|
(Resending with proper subject…)
Hm… that gives me an idea: assume that everything works as advertised and that the child process gets copies of the socket descriptors (which can be closed safely without intefering with the parent). If I’m right, the Socket instances in the image hold on to the address of the *parent* handle (in an inst var). So now, when I close a socket with #primSocketDestroy:, the handle passed to the plugin will be the handle of the parent socket (although it sounds strange that the child should be able to close a file descriptor of its parent…). 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…).
OSProcess uses plain fork() (in forkSqueak()). That’s what I use from the image.
From my understanding the file descriptors should be copied (fork). So that shouldn’t happen (but see above…).
|
|
|
(Resending with proper subject…)
True, I’d never thought of that…
That’s what I’m trying to do. The problem I face is that the database queries run in a separate process (Smalltalk process in the VM). Once I’m in the child process, there’s always a small window in which the scheduler might run that process before I can terminate it or do something else. My understanding from the C code (from reading man fork(2) and man clone(2)) is that sending Socket>>destroy (which does a close()) shouldn’t have any effect on the socket in the parent. My guess is that things get hairy when the process with the database queries gets processor time before I can destroy the sockets. When that happens, I suddenly have two processes reading from AND writing to the same socket (which can’t be good…). I just realized, there are BlockClosure>>valueUnpreemptively and BlockClosure>>valueUninterruptably. Maybe a can wrap the the code in the fork into such a block somehow to prevent the other processes from running? Thanks Dave.
|
Re: [Vm-dev] [OSProcess] forking and file descriptors
|
|
In reply to this post by Max Leske
> On 09 Jan 2015, at 9:32 , Max Leske <[hidden email]> 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. 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 , 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. Cheers, Henry |
|
|
In reply to this post by Max Leske
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.
True. But I really don’t want to maintain a branch of OSProcess :)
|
Re: [Vm-dev] [OSProcess] forking and file descriptors
|
|
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... Cheers, Henry |
|
|
In reply to this post by Max Leske
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. It wouldn't be a branch of OSProcess, but an update to the platform SocketPlugin sources. 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
|
Re: [Vm-dev] [OSProcess] forking and file descriptors
|
|
In reply to this post by Max Leske
On Fri, Jan 09, 2015 at 09:32:53AM +0100, Max Leske wrote:
> > OSProcess uses plain fork() (in forkSqueak()). That???s what I use from the image. > > > If their memory is shared (clone) instead of copied (fork), you might be kicking the feet out from under the parent image as well, so to speak??? > > From my understanding the file descriptors should be copied (fork). So that shouldn???t happen (but see above???). > The method comment in UnixOSProcessPlugin>>forkSqueak may be helpful, so I will copy it here: forkSqueak "Fork a child process, and continue running squeak in the child process. Answer the result of the fork() call, either the child pid or zero. After calling fork(), two OS processes exist, one of which is the child of the other. On systems which implement copy-on-write memory management, and which support the fork() system call, both processes will be running Smalltalk images, and will be sharing the same memory space. In the original OS process, the resulting value of pid is the process id of the child process (a non-zero integer). In the child process, the value of pid is zero. The child recreates sufficient external resources to continue running. This is done by attaching to a new X session. The child is otherwise a copy of the parent process, and will continue executing the Smalltalk image at the same point as its parent. The return value of this primitive may be used by the two running Smalltalk images to determine which is the parent and which is the child. The child should not depend on using existing connections to external resources. For example, the child may lose its connections to stdin, stdout, and stderr after its parent exits. The new child image does not start itself from the image in the file system; rather it is a clone of the parent image as it existed at the time of primitiveForkSqueak. For this reason, the parent and child should agree in advance as to whom is allowed to save the image to the file system, otherwise one Smalltalk may overwrite the image of the other. This is a simple call to fork(), rather than the more common idiom of vfork() followed by exec(). The vfork() call cannot be used here because it is designed to be followed by an exec(), and its semantics require the parent process to wait for the child to exit. See the BSD programmers documentation for details." | pid intervalTimer saveIntervalTimer | <export: true> <returnTypeC: 'pid_t'> <var: 'pid' type: 'pid_t'> <var: 'intervalTimer' type: 'struct itimerval'> <var: 'saveIntervalTimer' type: 'struct itimerval'> "Turn off the interval timer. If this is not done, then the program which we exec in the child process will receive a timer interrupt, and will not know how to handle it." self cCode: 'intervalTimer.it_interval.tv_sec = 0'. self cCode: 'intervalTimer.it_interval.tv_usec = 0'. self cCode: 'intervalTimer.it_value.tv_sec = 0'. self cCode: 'intervalTimer.it_value.tv_usec = 0'. self cCode: 'setitimer (ITIMER_REAL, &intervalTimer, &saveIntervalTimer)'. pid := self fork. "Enable the timer again before resuming Smalltalk." self cCode: 'setitimer (ITIMER_REAL, &saveIntervalTimer, 0L)'. ^ pid |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |