Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <021a01c0e00b$e8d48dc0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
References: <20010518221107 DOT A12195 AT redhat DOT com>
Subject: Re: pthread gotchas
Date: Sat, 19 May 2001 12:32:10 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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-OriginalArrivalTime: 19 May 2001 02:25:19.0780 (UTC) FILETIME=[F3041640:01C0E00A]

----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
Subject: pthread gotchas


> (I'll bet that this got Robert's attention)

Nope not at all. :]

> Just to be clear up front, the gotchas I'm talking about are my
gotchas.
> There were apparently some aspects of the way that pthreads work that
I
> was not familiar with.

Same here. :]

> I am looking into finally getting signals working in a multi-threaded
> enviroment given Corinna's recent problems with cygrunsrv.  So, I
> wrote a program which forked, started a separate thread, and then
> called waitpid().  I wanted to see how a SIGINT with a signal handler
> would work with pthreads.  I ran the program on linux.

Let me see if I understand this correctly: foo(pid,procthreadid)
foo(1,1) starts
foo(1,1) forks, giving foo(2,1)
foo(1,1) starts a new thread foo(1,2)
foo(1,2) calls waitpid(2,&loc,opt)
?

Reading http://www.opengroup.org/onlinepubs/007908799/xsh/wait.html
that should work. (Implied by two things: it's a process child that
matters, and multiple threads are allowed to waitpid on the same child
process).

**** MOST IMPORTANT ****
I think delivering signals to threads is broken. I cannot see where you
use getthread2signal in signal.cc. That would break waitpid the way you
see it broken.
**** ****

> I was surprised to find out that waitpid failed in this scenario.
> Apparently this was due to the fact that fork was called in the
> main thread and waitpid was called in a secondary thread.

Well, a bug in cygwin ;]

> I hadn't anticipated this behavior when I wrote the process handling
> years ago, even though I thought I was cleverly making things thread
> safe.
>
> So, my question is, is this standard pthread behavior?  I know that
> linux's pthread implementation has been through a couple of
iterations.
> I don't know if it is fully compliant or not.

I don't believe so. I think that this is wrong.

> Is there other stuff that will work this way as well?  For instance,
> will strtok (not strtok_r) work right?  I'm wonder how many of my
> misguided perceptions I need to examine.

strtok is not guaranteed threadsafe. It should never be used within
cygwin, and never used by multi-threaded applications.

> I've searched the net for a pthreads tutorial but the only ones I've
> been able to find are really basic.  Does anyone have a recommendation
> for a good reference?

Uhmm, writing a pthread library seems to be the qualifier :]

> cgf
>