Re: [AD] proposed patch for nicer asm symbols exports

[Chris <kcat@xxxxxxxxxx>]

Sam Hocevar wrote:
>    Well, it's the CPU/memory tradeoff. There is a CPU hit when using
> -fPIC but not using it uses more memory when several programs use the
> shared object. So it's definitely not worth using it in the libc for
> instance, but admittedly you will seldom run several binaries using
> liballegro at the same time.

If I'm understanding this right, you definately do *not* want the global 
memory segment Allegro has to be constant across programs. Just imagine 
what'd happen if Program #1 sets a gfx mode, then Program #2 sets a 
different mode. Program #1 would suddenly find itself in a situation 
that would be near-impossible to protect against.

An example: one program calls blit(..., screen, ...) as another calls 
set_gfx_mode(...). The 'screen' variable, and every other associated 
resource, would change /as it's being used/. Very, very bad. True, 
mutex's help protect against this somewhat, but every program would 
still have to be aware that the video mode can change at anytime, and 
you must be prepared to deal with it. The same goes with sound and input.

Now, while Allegro currently is unable to deal with its resources shared 
across programs, it /is/ possible to redesign it to. In the case of gfx, 
having the seperate "display bitmaps" as A5 planned would solve this. 
Each Allegro program would create a unique siplay bitmap that is not 
shared across programs, unlike "screen". That also has the added benefit 
of a single program being able to handle multiple modes.

- Kitty Cat