From: gunther DOT ebert AT ixos-leipzig DOT de (Gunther Ebert) Subject: Re: quest for thread-safeness!? 20 Oct 1997 05:09:00 -0700 Message-ID: <344B3DDE.5AFF.cygnus.gnu-win32@ixos-leipzig.de> References: <199710200906 DOT LAA02155 AT carol DOT wins DOT uva DOT nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Boncz Cc: gnu-win32 AT cygnus DOT com 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 > "gnu-win32-request AT cygnus DOT com" 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:gunther DOT ebert AT ixos-leipzig DOT de www : http://www.ixos-leipzig.de - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".