Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Dec 1999 18:10:03 -0800 (PST)
From:      nnd@mail.nsk.ru
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: bin/15328: Threaded "system" does'nt work in -current
Message-ID:  <199912080210.SAA19379@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/15328; it has been noted by GNATS.

From: nnd@mail.nsk.ru
To: Chris Piazza <cpiazza@jaxon.net>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/15328: Threaded "system" does'nt work in -current
Date: Wed, 8 Dec 1999 08:04:42 +0600 (NOVT)

 In <199912071850.KAA79377@freefall.freebsd.org> Chris Piazza <cpiazza@jaxon.net> wrote:
 > The following reply was made to PR bin/15328; it has been noted by GNATS.
 > 
 > From: Chris Piazza <cpiazza@jaxon.net>
 > To: nnd@mail.nsk.ru
 > Cc: FreeBSD-gnats-submit@FreeBSD.ORG
 > Subject: Re: bin/15328: Threaded "system" does'nt work in -current
 > Date: Tue, 7 Dec 1999 10:44:15 -0800
 > 
 >  > 	Compile the following program with the command:
 >  > 
 >  > cc -Wall -O -o systest -pthread systest.c
 >  > 
 >  > 	and start it by "./systest" -
 >  > 
 >  > you see the "date" output, but the program does'nt finish
 >  > (and cant be killed by SIGINT, but successfully killed by
 >  > SIGTERM).
 >  
 >  This program is working fine on my system.  My -current is from the 5th
 >  of december, though.  Do you think that's relevant?
 
 	It seems to me that the commit causes this (mis)behavior
 of the "system" function in threaded programs is cited down this
 letter. What are the versions of the relevant files in your
 sources ? 
 
 	N.Dudorov
 
 =================================================================== 
 >deischen    1999/12/04 14:55:59 PST
 >
 >  Modified files:
 >    lib/libc_r/uthread   pthread_private.h uthread_fork.c 
 >                         uthread_sig.c uthread_sigwait.c 
 >  Log:
 >  Change signal handling to conform to POSIX specified semantics.
 >  Before this change, a signal was delivered to each thread that
 >  didn't have the signal masked.  Signals also improperly woke up
 >  threads waiting on I/O.  With this change, signals are now
 >  handled in the following way:
 >  
 >    o If a thread is waiting in a sigwait for the signal,
 >      then the thread is woken up.
 >  
 >    o If no threads are sigwait'ing on the signal and a
 >      thread is in a sigsuspend waiting for the signal,
 >      then the thread is woken up.
 >  
 >    o In the case that no threads are waiting or suspended
 >      on the signal, then the signal is delivered to the
 >      first thread we find that has the signal unmasked.
 >  
 >    o If no threads are waiting or suspended on the signal,
 >      and no threads have the signal unmasked, then the signal
 >      is added to the process wide pending signal set.  The
 >      signal will be delivered to the first thread that unmasks
 >      the signal.
 >  
 >  If there is an installed signal handler, it is only invoked
 >  if the chosen thread was not in a sigwait.
 >  
 >  In the case that multiple threads are waiting or suspended
 >  on a signal, or multiple threads have the signal unmasked,
 >  we wake up/deliver the signal to the first thread we find.
 >  The above rules still apply.
 >  
 >  Reported by:	Scott Hess <scott@avantgo.com>
 >  Reviewed by:	jb, jasone
 >  
 >  Revision  Changes    Path
 >  1.30      +7 -3      src/lib/libc_r/uthread/pthread_private.h
 >  1.15      +4 -1      src/lib/libc_r/uthread/uthread_fork.c
 >  1.21      +66 -24    src/lib/libc_r/uthread/uthread_sig.c
 >  1.12      +6 -3      src/lib/libc_r/uthread/uthread_sigwait.c
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912080210.SAA19379>