-----BEGIN PGP SIGNED MESSAGE-----
wilson@cs.utexas.edu (Paul Wilson) writes:
> Why not? Can't spawn be implemented in terms of fork, but
> not vice versa?
You will have to cough up a spawn manpage for me;
I use 4.4 and 4.3-reno derived systems, with the
occasional painful foray into StunOS, and none of
these have spawn.
I don't remember a spawn in Sloaris or IRIX either, but
I've successfully avoided those platforms lately.
It certainly wasn't in Edition VII Workbench or WECO
v6, and I don't remember it from System III or SVR[23]. :-)
- From your description, though:
> I was thinking that spawn might help with the size thing, on
> some platforms. You don't need to copy the scsh process's
> virtual address space to fork a child process---you get the
> spawn daemon to fork itself instead. (Maybe this doesn't
> matter because all decent UNIXes will do an efficient virtual
> copy.
spawn sounds remarkably like vfork(2), which appeared in
3 (yes, 3) BSD. vfork and fork are not too different in
modern BSD-based systems; the principal difference is that
the parent is put into P_PWAIT state to preserve the
synchronization semantics of the old pre-MACH vfork
(the parent waits until the child does an execve, for example)
The old vfork would avoid copying any resources like the u
structure or the virtual memory associated with any given
process, as a way of speeding up the often painfully slow
full blown fork, particularly in the days where the pager
was primitive (or nonexistant), and copy on write page
faulting was a dream.
Fork these days in modern BSD is pretty quick.
I don't know what spawn does on systems that do spawn.
Unfortunately, scsh's virtual address space will get
copy-on-writed very quickly if memory is being touched,
such as when creating or collecting garbage. Moreover,
scsh's "big" problem is how few pages are actually
sharable between unrelated scsh processes, rather than
sharability between a parent scsh process and it's
immediate child, although the latter is an issue too.
I gather that the new Scheme48 may address some of that,
but changing to some different implementation of "fork" is
only a win on architechtures where fork(2) approaches a
complete resource-copy down to ancient semantics of
completely swapping out the parent.
> On some UNIX platforms, I'd think spawn would be more efficient
> than fork.
As I said, I don't know spawn as a system call, but would
love to find out about it. Esoterica can be fun. :)
> I'd also like to support full-blown scsh on UNIX.
RScheme and relatives look interesting, and seeing a
full-blown scsh running in it would not be a bad thing.
Sean.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey
iQCVAwUBMgrq5USWYarrFs6xAQHfowP/dZk4WfLslUwKO8igmJ61zML/E6sBVXTv
PL1NGH1ugriNrlzTH97BZG419u1nKWfwVCEWBolZYFaRVtaIJlwnP9fV8bYbkNzU
fsrGF2LnfPoOIc3QPjTRpR+TdWAGA+Y4+RbWI7IFeysUHx2yUIuJUs6aNikv6kgl
ZiEt3+RM3Cw=
=/gkB
-----END PGP SIGNATURE-----
|