nanogui: nxSocket?
Subject:
Re: nxSocket?
From:
Jordan Crouse ####@####.####
Date:
12 Feb 2001 15:12:37 -0000
Message-Id: <3A87FE83.C1022533@censoft.com>
Doh! If Nano-X starts getting used dynamically, that global will cause
issues. I believe that when the library is first used, the data section
is mapped to memory and used for the duration of the life of the first
calling program. When means, subsequent programs use that same data
section for their own use (ie, only one copy of the library is loaded).
Therefore, any globals that may have been initalized when a program
starts up will still be effect for any subsequent programs. This has
far reaching effects, especially if someone uses the Nano-X window
manager. This has the potential to be fairly dangerous. Of course,
when the library is used statically, then the globals become part of the
compiled program, and they run in the processes own space, which is not
dangerous for other programs.
I will run a small test today to find out how complex the problem is,
and report the results back.
Jordan
PS: Greg - The solution is to register each program with the library
when it starts (like the SDL library does.. you know, with SDL_Init()..)
Lots of dynamic libraries do this to ensure that variables that should
be global to an instance (like nxSocket) are not propagated between
programs
(without the appropriate locks in place). It wouldn't be too bad to
have GrOpen() do double duty in this case.
Greg Haerr wrote:
>
> : In Nano-X, there is a global variable named nxSocket.
> : It makes a lot of troubles, when I try to create some dynamic
> : linking libraries (*.so) with static linking libnano-X.a.
>
> Why not just create a dynamic .so version of libnano-X?
>
> : Is there any possibility to get rid of this global nxSocket as well as
> : other global variables in the next version of Microwindows/Nano-X?
>
> What are you proposing, that we would store the connection
> information as per-thread local storage? We've got to keep
> the instance of the socket connection fd somewhere.
>
> Regards,
>
> Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
