Subject: Re: quest for thread-safeness!?
From: [email-masked] (Gunther Ebert)

20 Oct 1997 05:09:00 -0700
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Peter Boncz <[email-masked]>
Cc: [email-masked]

Peter Boncz wrote:
> 
> Hi all,
> 
> I just got a multi-threaded database server compiling, and
> apparently running - and now, a bit late admittedly.., I discover
> on the mailing-list that the gnu-win libraries are not thread-safe!
> I didn't crash until now, but that is presumeably a matter of time
> and luck.  Help!
> 
> So, I am in deep sh*t. Even ready to invest serious work on the
> library to help fix up things. What I would like to know of some
> knowledgeable gnu-win person is:
> - what are the plans of Cygnus Support Inc. in the area of
>         thread-safeness?
> - which sections of the system are not thread-safe?
>         (the newlib/ or also the winsup/ stuff?)
> - or are there any other problem areas?
> 

There are at least problems with functions which use static or global data,
for example strtok(). You may have some luck that your database server
probably doesn't make use of such functions. Since I don't know the source code 
of newlib/winsup exactly I cannot give you a list of functions which are
not thread safe.

> If it's just newlib that is the problem:
> - how difficult would it be make this one thread-safe, or replace it
>         by the gnu-libc?

From my point of view, implementing support of thread local storage in
gcc would make things much easier. MSVC knows a special keyword called
_threadlocal which can be used with global variables to make them 
thread local. The compiler stores thread local data in the .tls section
rather than in the .data section and the system allocates new memory for
thread local data on every thread startup.
By the way, implementing support of thread-local storage probably shouldn't be
as difficult as you would expect. Right now you can tell the compiler that it 
should store some data in a .tls section using some inlined assembler
instructions and it does also create the .tls section but
linking the program results in an invalid executable because the
linker doesn't know anything about .tls sections. Maybe a bfd or even ldscript hack
would solve this ...

> - is it even possible to 'overload' the gnu libc on top
>         of the cygnus system in order to get a thread-safe system?
> 

You may try the mingw32 package (http://www.geocities.com/Tokyo/Towers/6162/) 
which replaces the cygwin.dll by crtdll.dll (a C library which is shipped 
with any Win32 system, look into %windir%\system32). crtdll.dll is thread-safe, 
but it provides just a MSVC-like C library which means that you will not have
any POSIX support, but if the software which you are going to port uses
only ANSI C routines mingw32 would be an option for you.

> many thanks in advance..
> 
> Peter Boncz
> Magnum Database Research Project
> University of Amsterdam
> -
> For help on using this list (especially unsubscribing), send a message to
> "[email-masked]" with one line of text: "help".

-- 

Gunther Ebert
iXOS Anwendungs-Software GmbH
Angerstrasse 40-42
D-04177 Leipzig

Phone : +49 341 48503-0
Fax   : +49 341 48503-99
E-mail: mailto:[email-masked]
www   : http://www.ixos-leipzig.de
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".