From owner-freebsd-threads@FreeBSD.ORG Wed Jan 25 23:13:42 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C83B416A420; Wed, 25 Jan 2006 23:13:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8351C43D46; Wed, 25 Jan 2006 23:13:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 25 Jan 2006 15:13:42 -0800 Message-ID: <43D80626.7030003@elischer.org> Date: Wed, 25 Jan 2006 15:13:42 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> In-Reply-To: <43D802DF.9040003@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Jose-Marcio.Martins@ensmp.fr, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 23:13:43 -0000 Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: > >> Julian Elischer wrote: >> >>> Jose Marcio Martins da Cruz wrote: >> >> >> >>> >>> a new threading library. >> >> >> >> Hmmmm. >> >> Here are my compile flags : >> >> CPPFLAGS : only some -I and -D flags >> CFLAGS : -D_THREAD_SAFE -pthread >> LDFLAGS : -lmilter -lkvm -lm -lpthread >> >>> >>> have you tried 6.0? >> >> >> Yes. It presents the same behaviour. Either way, I've found it with >> 6.0, and tried back with previous versions till find when the change >> took place. >> >>> also, does the child do an exec() after forking? >> >> >> >> No. The child gets out the father loop and calls another >> initialisation function. > > > > The Posix spec says that after a fork(0 teh child must do almost > nothing before calling exec() > and that AT A MAXIMUM it should only call async-safe functions. (i.e. > functions that can be called from > within signal handlers). > > There is all sorts of state being kept for the "now non existant" > threads in that address space. > > For example, some of them will still exist if they were stopped in > user space at the time, > but some of them will not (if tehy were in the kenrel at teh time). In > addition, > the process will now be marked "non threaded" in the kernel, as it now > only > has one kernel thread (as specified by posix) so an attempt to > schedule another thread > from user space will lead to unknown behaviour. The child will most > likely > run for a bit and then freeze up or die in some mysterious way. ( > sound familiar?). I might add that you can also try libthr instead of libpthread. They are compatible but use different methods to achieve their results. and thus have different failure modes. However relying on such thing sis not wise. I think the Linux thread people tried very hard to allow people to do as much as possible after the fork, however there are limitations there too. You shouldn't keep running "forever" in this way after a fork. How often does this forking occur? would an exec (argv[0]....., "aschild",); be a practical thing? Does the parent have to have become threaded before forking the children? This is a posix restriction. > > > > > > >> >> As It seemed to me that all father's threads are stopped in the >> forked process, this seemed to me not be a problem. Am I right ? > > > > no. Nothing has told the user half of the threading system about this. > >> >> The signal handler thread is launched by the following sequence of >> instructions. >> >> sigemptyset(&set); >> >> sigaddset(&set, SIGHUP); >> sigaddset(&set, SIGTERM); >> sigaddset(&set, SIGINT); >> sigaddset(&set, SIGUSR1); >> sigaddset(&set, SIGUSR2); >> >> if ((r = pthread_sigmask(SIG_BLOCK, &set, NULL)) != 0) >> { >> errno = r; >> LOG_SYS_ERROR("Couldn't mask signals"); >> } >> >> if ((r = pthread_create(&tid, NULL, filter_signal_handler, NULL)) >> != 0) >> LOG_SYS_ERROR("Error launching filter_signal_handler"); >> >> Thanks for your help. >> >> José-Marcio >> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org"