[EMAIL PROTECTED] (Lars Gullik Bjnes) wrote:
> | SIGSEGV is indeed occured in gs. This can be a bug in gs, but it is
> | more likely a LyX problem. Since gs was a *forked* child, not a *spawned*
> | child,
>
> What is the difference?
On UNIX the only way to create a new process is to fork an existing process
with the system call of the same name. This is achieved by copying the
pointers in the process information block of the parent to the newly allocated
block in the kernel.
On the other hand, on DOS (Windows included) and on OS/2 (Windows NT included)
there is no "fork" system call but there is a "spawn" instead. This system
call just allocate a new process information block. Only file handles and
the environment variable space is inherited and selectors to the address space
of the parent process are not copied. So the child cannot access the contents
of the memory of the parent.
In fact, OS/2 and Windows NT, it is impossible to implement "fork" in the same
way as on the UNIX, since even root has only read access to the PIB table in
the kernel. On DOS and Windows 95/98 where the kernel is not properly protected,
it may be possible, though.
EMX library function fork() is actually spawn system call with a little bit of
IPC to copy memory contents. It is inefficient because all the memory contents
rather than just pointers are copied.
Well, the difference I was talking was that a *spawned* child has a clean address
space, while a *forked* one might have a corrupted one.
BTW Arnd, please refrain from mixing a FUD into a citation (from EMX doc)
> fork() doesn't work correctly in multithread programs. [e.g. X11 apps]
which is simply untrue! Arnd, I understand you are under stress: figinset.C
is a mess. All I can say is that fprintf() is a better friend than gdb, this
time. How about saving all the postscript command LyX sends to gs in separate
file(s).
Regards,
SMiyata
