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

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

> Wouldn't it be easier to have your program separated?
> 
> So you let the AES/ENVironment multitask like it was meant to. And not
> trying to recreate a sub_layer of multitasking within 1 single
> application. 
> 
> Just an idea, I am *not* a specalist, but t worked for me with jpegem.
> Conversion going on and the GEM interface still responds.

For simple purposes, yes, it can be better. However, the forking has some
advantages.

For example, the child and the parent share same TEXT segment (no need to
load another binary), the child automintically inherits a copy of parent's
DATA and BSS (so it can use variables preinitialized by the parent). It
also inherits a copy of parent's file descriptors (so stdin/out/err can be
easily redirected for the child by the parent - useful for GEM shells of
text based programs) etc. etc.

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.

> Might not be the most elegant way, but it works.

Pfork() works too :-)

--
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.