[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] fVDI issues

>> You mean that these will be protected equally as the kernel itself,
>> right?
>
> No, modules fall under normal memory allocation after the kernel is
> initialized.

Aha, so you want to put all the AES as an XDD module. I somehow overlooked
this information.

> Looking at the changelog ... the relevant change is from charon with
> the following log message (I don't changed anything on this file at
> all):
>
> revision 1.5
> date: 2003/11/23 21:33:49;  author: charon;  state: Exp;  lines: +3 -1
> marked the "not must"-stuff listed by draco

Well, let it be charon, nonetheless you are the coordinator and you have
apparently approved this.

>> Well, no, not exactly. The problem is, that the AES, when
>> reading/writing the application global array, never knows, whether
>> the DATA/BSS is the one of the parent, or the one of the child. When
>> the parent has created the child with fork(), that is. This is so
>> because the AES is a separate process, which runs asynchronously to
>> the two. A library routine is not a separate process, so there would
>> be no troubles I suppose - always the proper DATA/BSS would be
>> accessed.
>
> Sure, but you still need to detect a fork. Or you must fork all
> windows
> and other elements on the screen too (e.g. requires special support
> by the screen manager -> special kernel support; the same as I
> already wrote).

I must say that I don't follow in this point. It seems to me, that I only
need this when I want fork() to automatically make child be a GEM
application, if the parent is a GEM application. I am not so sure that this
is really desired.

Otherwise I can't see why registering the child process with appl_init()
must require the AES be fork-aware: the AES application arrays must be
separate for each GEM application anyways (one pid = one array), regardless
of anything. This is solved by the gemlib, with the mt-support. And there
will be no problems with synchronization, because no synchronization will be
necessary, since the AES will not be an user process anymore.

--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy. (T. Liuius XXIV, 25).