Re: [MiNT] Calling GEM from within a signal handler

[Konrad Kokoszkiewicz <draco@mi.com.pl>]

> > Finally, if you write a program that handles multiple, but similar GEM
> > windows - like image viewer or something - you can basically write a
> > program that handles ONE window, then duplicate it using fork as many
> > times as many windows you need. Just an example.
> 
> Uh, I don't want to measure the time context switches between all these
> tasks take, then ... Using MiNT's Pfork() has the problem that - to
> really have independent data/bss and allocated memory blocks - a context
> switch between two such instances of a process requires copying of all
> that, due to the lack of a virtual address space. (Yes, such a beast
> would be possible for >= 020, but plain old STs won't ever see a virtual
> address space.)

Of course, I realize that, but this is not what is being discussed. This
is an "elegant" and "cheap" way of creating a thread inside application
(so it is application development level) and that is what was originally
asked about - as I understood. But to say that the kernel solves it in
"unelegant" way, we must go down to kernel development level to discuss
what we possibly can do to make it better. That last has nothing to do
with the particular question of application development.

And, btw, since MiNT seems to be mostly used on MMU equipped machines
(Falcons, TTs, clones), perhaps it could be advantageous to think of
memory virtualization on 68030+ (keeping the old way for 68000 machines as
long as it is possible).

--
Konrad M.Kokoszkiewicz
|mail: draco@mi.com.pl                  | Atari Falcon030/TT030/65XE |
|http://www.obta.uw.edu.pl/~draco/
|http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.