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

[Sam Hocevar <sam@xxxxxxxxxx>]

On Fri, Aug 20, 2004, Chris wrote:
> 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.

   No, only the text segment (== the code and various constant stuff) is
shared across programs. No operating system designer in their right mind
would share the data segment across programs! (well, sometimes you need
to, that's what shm is here for, but it's a completely different matter)

   The problem discussed here is only a performance problem due to how
the operating system handles shared libraries and into which parts of
the code needs to be duplicated in memory.

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

   But modern operating systems have ways to share the display (through
windowed contexts) and the sound device, and your window handle
definitely does not change when the video mode changes. As for input,
most of the time the application that has focus gets it; again this is
handled by the operating system.

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

   I don't quite understand, here. At least on X11, OS X and DirectX,
the screen is not shared between applications, each instance of
liballegro has a handle to its display area and the operating system
multiplexes them on screen.

-- 
Sam.