[squeak-dev] Re: [Vm-dev] [OSProcess] forking and file descriptors

David T. Lewis lewis at mail.msen.com
Fri Jan 9 12:51:43 UTC 2015

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:

	"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

	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

More information about the Vm-dev mailing list