On 20 Aug 1999 22:59:42 +0900, [EMAIL PROTECTED] wrote:
>[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?
>
>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!
Unfortunately not! It *is* a citation of the emx docs:
Cf. "emx 0.9c Application Developer's Guide: Chapter 12: Known
Problems: Paragraph 6".
I cited it in this place, because it summarizes the restrictions
detailed in the following cited paragraphs.
>Arnd, I understand you are under stress:
not so much ;-) it still has to be fun too... But I understand well
that you - amongst other X/2 programmers - took all precautions to make
fork() work, despite it's inherent restrictions.
So this cite of emx docs was not meant against your careful work, only
to propagate also consideration of other spawning methods (like
spawnxx() "PC", system() "C90") or even stellar threading to make LyX
more responsive on slow systems (DOSCreateThread() "OS/2-traditional",
_beginthread() "winxx/emx", pthread-create() "Linux/X.Leroy", etc.)
when creating a new portability design. The latter has the problem of
fewer crash protection than fork(), but it uses less resources, is
faster and should be easy to implement on most modern Unices.
Please don't interpret me again wrongly here: Consideration means
taking this into account when designing, so that porting becomes a bit
easier; it does not mean: Implementation.
>figinset.C is a mess.
I can confirm this... Here bug-hiding became almost real work.
>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).
Already done... :)
What I found was that the commands passed to gs appear to work:
The inline figure is printed to screen on my box when the exact
commands as passed by LyX are given to gs in an xterm, though the
printed figure immediately disappears from the screen when gs exits...
But LyX's own Xdisplay space for painting seems to be blocked for gs.
I even tried to replace fork by spawn as far as possible (not too
difficult), but to no avail. Maybe I introduced another bug here.
Attached follows the very experimental code with my changes. Maybe some
idea there is a bit helpful.
Greets,
Arnd
render-spawn.patch.gz
