Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Message-ID:	<002901c0d47c$255059f0$78752ec3@dima>
From:	"Dmitry Timoshkov" <dmitry AT sloboda DOT ru>
To:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc:	<cygwin AT cygwin DOT com>
Subject:	Re: oldhand cygwinner needed: RE: __errno_location() like functionality in Cygwin
Date:	Fri, 4 May 2001 17:23:58 +0800
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRcpt-To:	cygwin AT cygwin DOT com
X-MDRemoteIP:	195.46.117.120
X-Return-Path:	dmitry AT sloboda DOT ru
X-MDaemon-Deliver-To:	cygwin AT cygwin DOT com

First of all, thank you very much for your reply.

"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au> wrote:

[...]
> > I searched archives of this mailing list and have read FAQ 
> > and documentation about
> > two possible ways to achieve reentrancy using reent struct. 
> > The first method requires
> > to replace all standard library calls by their _*_r 
> > equivalents. That's not an option.
> 
> Why not? If you are writing threaded applications, you must either a)
> use thread safe library functions or b) syncronise your code. If you
> have taken option b) then you are already thread safe. If you have not
> taken option b) then you are using functions that are not guaranteed
> thread safe (_r functions usually are, but a lot of non _r functions are
> also guaranteed thread safe. The point is that option a) involves
> checking).

I'm not writing a threaded application, I'm going to port an existing one,
which contains a lot of lines of code. Moreover, interoperability with the
existing application is one of the requirements: i.e. bug fixes and improvements
from the one side should be easy applied to another one. That application
uses only those libc calls which are supposedly thread safe, and has no
any problems running in Linux. Having thread local errno variable is enough.

> > The second method requires to assign _impure_ptr to the 
> > pointer of thread local reent
> > structrure before EVERY libc call. Am I understand it correctly?
> 
> Uhmm, I have no idea what you mean here. You should have _no_ static
> variables that are unguarded (ie don't use mutexs) and all global
> structs should have their access guarded.

From the info regarding reentrancy in libc:
-----
   This means that you have two ways to achieve reentrancy.  Both
require that each thread of execution control initialize a unique global
variable of type `struct _reent':

  1. Use the reentrant versions of the library functions, after
     initializing a global reentrancy structure for each process.  Use
     the pointer to this structure as the extra argument for all
     library functions.

  2. Ensure that each thread of execution control has a pointer to its
     own unique reentrancy structure in the global variable
     `_impure_ptr', and call the standard library subroutines.
-----
I meant the option 2 above.

> As for errno in cygwin I'm not sure off the top of my head as to it's
> thread safeness... comments anyone?

That is the core of my question.

Thanks for your kind answers.
--
Dmitry.



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -