On 25 Nov 1999 02:48:49 +0100, Lars Gullik Bj°nnes wrote:
>| Well, in the old dll version I had to export some uninitialized
>| globals, what I did not like.
>
>Do you have a list of them? We should not have uninitialized globals.
Unfortunately I did not keep a list. I think 1.0.4 finally got rid of
most of them, the experiments date back from 1.0.3 (The released DLL
mainly contains C functions: libforms, libxpm, libintl and few basic
classes like LString, which don't share common global memory objects
with LyX.
Putting more into a DLL would break the fork() emulation, because of
common usage of malloc'ed ('new') resources in the DLL. Here emx is not
always able to keep track of all the memory areas to be copied when
fork()ing. So it flags ENOMEM.)
I'm nevertheless unsure, if all global variables (initially declared in
lyx_main.C) and most used in lyx_cb.C were already initialized. This is
104's lyx_main.C:
// Should this be kept global? Asger says Yes.
Error lyxerr; [=0]
LastFiles *lastfiles; [add = NULL ??]
LyXRC *lyxrc; [add = NULL ??]
// This is the global bufferlist object
BufferList bufferlist; [OK]
LyXServer *lyxserver = 0;
// this should be static, but I need it in buffer.C
bool finished = false; // flag, that we are quitting the
program
// convenient to have it here.
kb_keymap *toplevel_keymap; [add = NULL ??]
I used:
// this should be static, but I need it in buffer.C
bool quitting = false; // flag, that we are quitting the
program
bool finished = false; // all cleanup done just let it run through
now.
[the usage of 'finished' is a bit unclear. This what grep says:
figinset.C:1151: bool finished = false;
figinset.C:1153: while (lex.IsOK() && !finished) {
figinset.C:1162: finished = true;
filetools.C:722: // No EndChar inside. So we are
finished
layout.C:284: bool finished = false;
layout.C:287: while (!finished && lexrc.IsOK() && !error) {
layout.C:299: finished = true;
layout.C:1311: bool finished = false;
layout.C:1316: while (lex.IsOK() && !finished) {
layout.C:1319: finished = true;
lyxfont.C:494: bool finished = false;
lyxfont.C:495: while (!finished && lex.IsOK() && !error) {
lyxfont.C:503: finished = true;
lyx_cb.C:98:bool finished = false; // all cleanup done just let it run
through now.
lyx_cb.C:1007: finished = true;
lyx_gui.C:77:extern bool finished; // flag, that we are quitting
the program
lyx_gui.C:632: while (!finished) {
bool scrolling = false; [OK]
/* whether the work area should get callbacks */
bool input_prohibited = false; [OK]
/* the selection possible is needed, that only motion events are
* used, where the bottom press event was on the drawing area too */
bool selection_possible = false; [OK]
>| Nevertheless, cleaning up this structure
>| would be great for all LyX platforms, I think, not only Linux. And I
>| like very much the old idea of SMiyata: Put the whole LyX kernel, with
>| the exception of main(), into shared modules. This would give us
>| several instances (windows) of LyX without additional overhead and with
>| crash protection in separate processes.
>
>On most operating systems (eg. unix) you get that with statically
>linked binaries too. Dynamic libs are only a gain when several
>_different_ applications want to use the libs.
?? I don't get the idea.
Is it cloning an app with an bsd-like vfork()ed light-weight
process (or fork() of Linux, i.e. in fact vfork())? But you cannot
clone on the commandline, you have to start _different_ apps, i.e.
processes. And vfork() is not very safe, no real mutual memory
protection among clones, etc.
>
>| * ditch completely fork() syscall: This is easy to implement for the
>| syscalls class, did this already, I don't see a problem to port it to
>| the new branch. This is certainly not a top priority, but as it is not
>| so much work, I think I can do it easily.
>
>agree, child processes should be made witht eh syscalls class.
>
>| * ditch figinset.C: I could not make it work on my box, probably a
>| problem of gs403, which I must use here. You use some forked workhorse
>| process clones; this is not always guaranteed to work with emx a.out
>| and is guaranteed not to work in a DLL. So: Reimplement this in a
>| thread safe re-entrant way (protect variables and other resources
>| against mutual competition, etc.), but do not call (i.e. select) the X
>| server in the work horse at all; unfortunately, the emx select() call
>| is not thread safe :-/.
>
>There are other ways to do this when you use threads.
>Notifiers f.ex.
>
>You let the spawning thread block on a read from the Notifier Queue,
>and the spawned threads will write a notify on the Notifier Queue,
>this will wake up the spawning thread.
I've found at least two blocking methods: mutex semaphores and
muxwait semaphores with multiple subclasses. Queues they use normally
for presentation manager multithreading, I think.
>That is the idea. The idea is to have a InsetGraphics that requests a
>pixmap given a filename.
>
> InsetGraphics
> ^ |
> | |
> pixmap filename
> | |
> | v
> ImageContainer
>
>The ImageContainer is a module that knows how to create pixmaps out of
>different image types. And we really don't care what method is used to
>create the pixmaps, if is gs, IMLIB, toolkit native functions, or whatever.
>(in the case of gs...we do it without letting it connect to the
>Xserver)
>
>The InsetGraphics knows about the display, ImageContaner does not.
>
>I would like the ImageContainer to store the converted files on disk
>in stead of in memory.
I think multi-threading should be easier here, because there will be no
obvious conflicts for resource access.
Greets,
Arnd
