From owner-freebsd-threads@FreeBSD.ORG Mon Jan 23 11:02:52 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 148B816A41F for ; Mon, 23 Jan 2006 11:02:52 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F64043D53 for ; Mon, 23 Jan 2006 11:02:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0NB2kF1086436 for ; Mon, 23 Jan 2006 11:02:46 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0NB2jpG086429 for freebsd-threads@freebsd.org; Mon, 23 Jan 2006 11:02:45 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 Jan 2006 11:02:45 GMT Message-Id: <200601231102.k0NB2jpG086429@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 23 Jan 2006 11:02:52 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [threads] [patch] Threaded applications e o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function o [2005/03/10] threads/78660threads Java hangs unkillably in STOP state after o [2005/04/08] threads/79683threads svctcp_create() fails if multiple threads o [2005/04/28] threads/80435threads panic on high loads o [2005/05/19] threads/81258threads Thread specific data is sometimes assigne o [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x o [2005/08/20] threads/85160threads [libthr] [patch] libobjc + libpthread/lib o [2005/11/19] threads/89262threads [kernel] [patch] multi-threaded process h o [2005/12/12] threads/90278threads libthr, ULE and -current produces >100% W o [2006/01/03] kern/91266 threads [threads] Trying sleep, but thread marked 29 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/04/13] threads/79887threads [patch] freopen() isn't thread-safe o [2005/05/13] threads/80992threads abort() sometimes not caught by gdb depen o [2005/05/26] threads/81534threads [libc_r] [patch] libc_r close() will fail 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Jan 25 22:52:20 2006 Return-Path: X-Original-To: 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 A547816A420 for ; Wed, 25 Jan 2006 22:52:20 +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 1510A43D46 for ; Wed, 25 Jan 2006 22:52:19 +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 14:52:19 -0800 Message-ID: <43D80123.5050503@elischer.org> Date: Wed, 25 Jan 2006 14:52:19 -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: threads@freebsd.org Content-Type: multipart/mixed; boundary="------------050500030300040701010603" Cc: Subject: [Fwd: 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 22:52:20 -0000 This is a multi-part message in MIME format. --------------050500030300040701010603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------050500030300040701010603 Content-Type: message/rfc822; name="Re: Changes from 5.2.1 to 5.3 (theads / signal handling)" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: Changes from 5.2.1 to 5.3 (theads / signal handling)" Received: from localhost.localdomain (mar92-6-82-226-38-60.fbx.proxad.net [82.226.38.60]) by idiom.com (8.12.11/8.12.11) with ESMTP id k0PKdgdO034379 for ; Wed, 25 Jan 2006 12:39:43 -0800 (PST) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from [127.0.0.1] (localhost. [127.0.0.1]) by joe.j-chkmail.org (sendmail X.1.0.PreAlpha1.0) with ESMTP id S000000000000024E01; Wed, 25 Jan 2006 21:39:33 +0100 Message-ID: <43D7E202.2020607@ensmp.fr> Date: Wed, 25 Jan 2006 21:39:30 +0100 From: Jose Marcio Martins da Cruz Reply-To: Jose-Marcio.Martins@ensmp.fr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer CC: freebsd-hackers@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> In-Reply-To: <43D7C786.1090803@elischer.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702080701060306070401" X-ClamAV-Status: No X-Spam-Status: No, hits=-1.6 required=5 tests=BAYES_00,RCVD_IN_SORBS_DUL, AWL X-Accessio-Status: NO, score=1.23,466590 version=6.0 count=2 X-Idiom-Reporting: If this was spam, please report it to http://www.spamcop.net This is a cryptographically signed message in MIME format. --------------ms040702080701060306070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: >=20 > 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=20 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 f= unction. As It seemed to me that all father's threads are stopped in the forked pr= ocess,=20 this seemed to me not be a problem. Am I right ? The signal handler thread is launched by the following sequence of instru= ctions. sigemptyset(&set); sigaddset(&set, SIGHUP); sigaddset(&set, SIGTERM); sigaddset(&set, SIGINT); sigaddset(&set, SIGUSR1); sigaddset(&set, SIGUSR2); if ((r =3D pthread_sigmask(SIG_BLOCK, &set, NULL)) !=3D 0) { errno =3D r; LOG_SYS_ERROR("Couldn't mask signals"); } if ((r =3D pthread_create(&tid, NULL, filter_signal_handler, NULL)) !=3D= 0) LOG_SYS_ERROR("Error launching filter_signal_handler"); Thanks for your help. Jos=E9-Marcio --------------ms040702080701060306070401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKKDCC BRAwggL4oAMCAQICAwHW9zANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNjAx MjExNDQ4MjBaFw0wNzAxMjExNDQ4MjBaMFMxJDAiBgNVBAMTG0pvc2UtTWFyY2lvIE1hcnRp bnMgZGEgQ3J1ejErMCkGCSqGSIb3DQEJARYcSm9zZS1NYXJjaW8uTWFydGluc0BlbnNtcC5m cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMyu8K6aUJMX2ZJP69UGRaB/gZ2W FzSXUpLmA+1lNGlc40X8D6N9mTwWX/IpI1Ppcxd9QYOBLm2M2Atc7IjV78MXj75dGYbOT0Dz YUovwoTGhKOYg18VIuxQ4rinGEI8eIqX6gMJ/Ftzox3H/og04AiIZxyMClAjuV5QFN7FRRtI uYGYgLaT+Hq5Q2LXizthF0ewXBfqH1GmJFyErhjkxWQTH4Dq8oFZuRnWA4V2Y30Ss6dn1mjx ySA3AsMaMNQTAZssa6R0BOqAFui3vm58zghLL23Mp5De2bpM83Y2mA8yqMEsF0DWr8Hi40a8 6xCYZHqKtTVxjeXqVRv5OxF8J/sCAwEAAaOBxjCBwzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVy IHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGG Fmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJwYDVR0RBCAwHoEcSm9zZS1NYXJjaW8uTWFydGlu c0BlbnNtcC5mcjANBgkqhkiG9w0BAQUFAAOCAgEAh0j3DWg17BIm//AnhNDPDwTbDZUBtI3b CPSXu3QZCvxSgkx980F8MxA2AJ0nW8BOH9siGYd/2KZX1N2juZqgz5H/kq8y5kSFAiMrqxWL Oy8YdaJak+NRATe1JXl0V1VBSVTgi3/QlpcaHgQgHa+GZq5qDnnQvRqYjeajNyLLBXLWBPiL w8rR/JwlMObaGEgaVggyNTtxBTHHf4bc0ErKdwV6y0P55kvvDqorYY5pQ1VZG2NQchfZHScs I4RBNSRx1Dnm8c9sFxR2EJ972HsqTkLunz43NKDHOF15KXv4ePSoRbdMcHTCTEEvPuYMv8rS i1bp0OlRdW1EWxT58MAI1nRGDbaAeAGRRVC6PfMx6QgGeyMQOL8ibK8NpXBIoMvggbxjF497 u1y5SnEfUCJdHDUpW0dzaTbh96tCfywdXxJTKfKivbrju3nnAqiMGMFX1+XJ2F444SD4eL76 Qbyme/vKsqvWsuKBB6+j1c8gyotKuke0HwQEOPc+zZ7YJUgLI/1ghrGdfB9h4qkvKjSyG4an iXZyvod+iFlszEcF5Y6N9jEwN+7zrRNlvQfY0xHgJNmKOP8Y7s8iflr9UTKPAWgKaxcDDFAJ 07zM98jB7jiOpIS3MhFDj/njtNzeCFpgrojM/X490841ME0EYeoDt7ZhhWMsu1/FGk3Ov4mv rNMwggUQMIIC+KADAgECAgMB1vcwDQYJKoZIhvcNAQEFBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MDYwMTIxMTQ0ODIwWhcNMDcwMTIxMTQ0ODIwWjBTMSQwIgYDVQQDExtKb3NlLU1hcmNpbyBN YXJ0aW5zIGRhIENydXoxKzApBgkqhkiG9w0BCQEWHEpvc2UtTWFyY2lvLk1hcnRpbnNAZW5z bXAuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMrvCumlCTF9mST+vVBkWg f4Gdlhc0l1KS5gPtZTRpXONF/A+jfZk8Fl/yKSNT6XMXfUGDgS5tjNgLXOyI1e/DF4++XRmG zk9A82FKL8KExoSjmINfFSLsUOK4pxhCPHiKl+oDCfxbc6Mdx/6INOAIiGccjApQI7leUBTe xUUbSLmBmIC2k/h6uUNi14s7YRdHsFwX6h9RpiRchK4Y5MVkEx+A6vKBWbkZ1gOFdmN9ErOn Z9Zo8ckgNwLDGjDUEwGbLGukdATqgBbot75ufM4ISy9tzKeQ3tm6TPN2NpgPMqjBLBdA1q/B 4uNGvOsQmGR6irU1cY3l6lUb+TsRfCf7AgMBAAGjgcYwgcMwDAYDVR0TAQH/BAIwADBWBglg hkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg b3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMCcGA1UdEQQgMB6BHEpvc2UtTWFyY2lvLk1h cnRpbnNAZW5zbXAuZnIwDQYJKoZIhvcNAQEFBQADggIBAIdI9w1oNewSJv/wJ4TQzw8E2w2V AbSN2wj0l7t0GQr8UoJMffNBfDMQNgCdJ1vATh/bIhmHf9imV9Tdo7maoM+R/5KvMuZEhQIj K6sVizsvGHWiWpPjUQE3tSV5dFdVQUlU4It/0JaXGh4EIB2vhmauag550L0amI3mozciywVy 1gT4i8PK0fycJTDm2hhIGlYIMjU7cQUxx3+G3NBKyncFestD+eZL7w6qK2GOaUNVWRtjUHIX 2R0nLCOEQTUkcdQ55vHPbBcUdhCfe9h7Kk5C7p8+NzSgxzhdeSl7+Hj0qEW3THB0wkxBLz7m DL/K0otW6dDpUXVtRFsU+fDACNZ0Rg22gHgBkUVQuj3zMekIBnsjEDi/ImyvDaVwSKDL4IG8 YxePe7tcuUpxH1AiXRw1KVtHc2k24ferQn8sHV8SUynyor2647t55wKojBjBV9flydheOOEg +Hi++kG8pnv7yrKr1rLigQevo9XPIMqLSrpHtB8EBDj3Ps2e2CVICyP9YIaxnXwfYeKpLyo0 shuGp4l2cr6HfohZbMxHBeWOjfYxMDfu860TZb0H2NMR4CTZijj/GO7PIn5a/VEyjwFoCmsX AwxQCdO8zPfIwe44jqSEtzIRQ4/547Tc3ghaYK6IzP1+PdPONTBNBGHqA7e2YYVjLLtfxRpN zr+Jr6zTMYIDhzCCA4MCAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0 cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwHW9zAJBgUrDgMCGgUAoIIB 2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAxMjUyMDM5 MzBaMCMGCSqGSIb3DQEJBDEWBBQLKjRbj+7qBwWcxogZ9YGuDZk5YjBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB 1vcwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB1vcwDQYJKoZIhvcN AQEBBQAEggEAhnyxcEW/cR4Pw9S4XP0c6U746if0a0Kn2hoqJkSAH1KiP7bAMWzxCS14is4x bY0DfPYpZT6Qj/INb+Rz3sHCnc9HBbJua8+skYNVMXk1iWc3+31xcQWBeFkDCBQO2McjewBi Yg13smP+swfbVi5zZlh2xdqRpI9wE5nzdIfLb4QNiO3OCd2zwJOq78i5PlG7JTF1laaZAhsq 8OAhEBla6y4b0J7OdQB/Tzi2NkkBdIZHoss8tUuODm5Z/xmrRbY63Z/MeDae6wbkoBivGxha B5fcvANOOC0tiSlNCn6Kbr/U4qCnDhT+xMdinALSwQBqzBj1mF3XAouqu/HUt9ReOAAAAAAA AA== --------------ms040702080701060306070401-- --------------050500030300040701010603-- From owner-freebsd-threads@FreeBSD.ORG Wed Jan 25 22:58:30 2006 Return-Path: X-Original-To: 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 D100C16A420 for ; Wed, 25 Jan 2006 22:58:30 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA2243D45 for ; Wed, 25 Jan 2006 22:58:30 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k0PMwN8T019082; Wed, 25 Jan 2006 17:58:23 -0500 (EST) Date: Wed, 25 Jan 2006 17:58:23 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <43D80123.5050503@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=------------050500030300040701010603 Content-ID: X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: threads@freebsd.org Subject: Re: [Fwd: 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 22:58:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------050500030300040701010603 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: On Wed, 25 Jan 2006, Julian Elischer wrote: >... I have no idea what this was trying to say, but the word fork() came out. A multithreaded process that forks may only call (in the child) async-signal-safe functions before calling one of the exec() functions. -- DE --------------050500030300040701010603 Content-Type: MESSAGE/RFC822; NAME="Re: Changes from 5.2.1 to 5.3 (theads / signal handling)" Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="Re: Changes from 5.2.1 to 5.3 (theads / signal handling)" Received: from localhost.localdomain (mar92-6-82-226-38-60.fbx.proxad.net [82.226.38.60]) by idiom.com (8.12.11/8.12.11) with ESMTP id k0PKdgdO034379 for ; Wed, 25 Jan 2006 12:39:43 -0800 (PST) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from [127.0.0.1] (localhost. [127.0.0.1]) by joe.j-chkmail.org (sendmail X.1.0.PreAlpha1.0) with ESMTP id S000000000000024E01; Wed, 25 Jan 2006 21:39:33 +0100 Message-ID: <43D7E202.2020607@ensmp.fr> Date: Wed, 25 Jan 2006 21:39:30 +0100 From: Jose Marcio Martins da Cruz Reply-To: Jose-Marcio.Martins@ensmp.fr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer CC: freebsd-hackers@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> In-Reply-To: <43D7C786.1090803@elischer.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702080701060306070401" X-ClamAV-Status: No X-Spam-Status: No, hits=-1.6 required=5 tests=BAYES_00,RCVD_IN_SORBS_DUL, AWL X-Accessio-Status: NO, score=1.23,466590 version=6.0 count=2 X-Idiom-Reporting: If this was spam, please report it to http://www.spamcop.net This is a cryptographically signed message in MIME format. --------------ms040702080701060306070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: >=20 > 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=20 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 f= unction. As It seemed to me that all father's threads are stopped in the forked pr= ocess,=20 this seemed to me not be a problem. Am I right ? The signal handler thread is launched by the following sequence of instru= ctions. sigemptyset(&set); sigaddset(&set, SIGHUP); sigaddset(&set, SIGTERM); sigaddset(&set, SIGINT); sigaddset(&set, SIGUSR1); sigaddset(&set, SIGUSR2); if ((r =3D pthread_sigmask(SIG_BLOCK, &set, NULL)) !=3D 0) { errno =3D r; LOG_SYS_ERROR("Couldn't mask signals"); } if ((r =3D pthread_create(&tid, NULL, filter_signal_handler, NULL)) !=3D= 0) LOG_SYS_ERROR("Error launching filter_signal_handler"); Thanks for your help. Jos=E9-Marcio --------------ms040702080701060306070401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKKDCC BRAwggL4oAMCAQICAwHW9zANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNjAx MjExNDQ4MjBaFw0wNzAxMjExNDQ4MjBaMFMxJDAiBgNVBAMTG0pvc2UtTWFyY2lvIE1hcnRp bnMgZGEgQ3J1ejErMCkGCSqGSIb3DQEJARYcSm9zZS1NYXJjaW8uTWFydGluc0BlbnNtcC5m cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMyu8K6aUJMX2ZJP69UGRaB/gZ2W FzSXUpLmA+1lNGlc40X8D6N9mTwWX/IpI1Ppcxd9QYOBLm2M2Atc7IjV78MXj75dGYbOT0Dz YUovwoTGhKOYg18VIuxQ4rinGEI8eIqX6gMJ/Ftzox3H/og04AiIZxyMClAjuV5QFN7FRRtI uYGYgLaT+Hq5Q2LXizthF0ewXBfqH1GmJFyErhjkxWQTH4Dq8oFZuRnWA4V2Y30Ss6dn1mjx ySA3AsMaMNQTAZssa6R0BOqAFui3vm58zghLL23Mp5De2bpM83Y2mA8yqMEsF0DWr8Hi40a8 6xCYZHqKtTVxjeXqVRv5OxF8J/sCAwEAAaOBxjCBwzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVy IHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGG Fmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJwYDVR0RBCAwHoEcSm9zZS1NYXJjaW8uTWFydGlu c0BlbnNtcC5mcjANBgkqhkiG9w0BAQUFAAOCAgEAh0j3DWg17BIm//AnhNDPDwTbDZUBtI3b CPSXu3QZCvxSgkx980F8MxA2AJ0nW8BOH9siGYd/2KZX1N2juZqgz5H/kq8y5kSFAiMrqxWL Oy8YdaJak+NRATe1JXl0V1VBSVTgi3/QlpcaHgQgHa+GZq5qDnnQvRqYjeajNyLLBXLWBPiL w8rR/JwlMObaGEgaVggyNTtxBTHHf4bc0ErKdwV6y0P55kvvDqorYY5pQ1VZG2NQchfZHScs I4RBNSRx1Dnm8c9sFxR2EJ972HsqTkLunz43NKDHOF15KXv4ePSoRbdMcHTCTEEvPuYMv8rS i1bp0OlRdW1EWxT58MAI1nRGDbaAeAGRRVC6PfMx6QgGeyMQOL8ibK8NpXBIoMvggbxjF497 u1y5SnEfUCJdHDUpW0dzaTbh96tCfywdXxJTKfKivbrju3nnAqiMGMFX1+XJ2F444SD4eL76 Qbyme/vKsqvWsuKBB6+j1c8gyotKuke0HwQEOPc+zZ7YJUgLI/1ghrGdfB9h4qkvKjSyG4an iXZyvod+iFlszEcF5Y6N9jEwN+7zrRNlvQfY0xHgJNmKOP8Y7s8iflr9UTKPAWgKaxcDDFAJ 07zM98jB7jiOpIS3MhFDj/njtNzeCFpgrojM/X490841ME0EYeoDt7ZhhWMsu1/FGk3Ov4mv rNMwggUQMIIC+KADAgECAgMB1vcwDQYJKoZIhvcNAQEFBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MDYwMTIxMTQ0ODIwWhcNMDcwMTIxMTQ0ODIwWjBTMSQwIgYDVQQDExtKb3NlLU1hcmNpbyBN YXJ0aW5zIGRhIENydXoxKzApBgkqhkiG9w0BCQEWHEpvc2UtTWFyY2lvLk1hcnRpbnNAZW5z bXAuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMrvCumlCTF9mST+vVBkWg f4Gdlhc0l1KS5gPtZTRpXONF/A+jfZk8Fl/yKSNT6XMXfUGDgS5tjNgLXOyI1e/DF4++XRmG zk9A82FKL8KExoSjmINfFSLsUOK4pxhCPHiKl+oDCfxbc6Mdx/6INOAIiGccjApQI7leUBTe xUUbSLmBmIC2k/h6uUNi14s7YRdHsFwX6h9RpiRchK4Y5MVkEx+A6vKBWbkZ1gOFdmN9ErOn Z9Zo8ckgNwLDGjDUEwGbLGukdATqgBbot75ufM4ISy9tzKeQ3tm6TPN2NpgPMqjBLBdA1q/B 4uNGvOsQmGR6irU1cY3l6lUb+TsRfCf7AgMBAAGjgcYwgcMwDAYDVR0TAQH/BAIwADBWBglg hkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg b3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMCcGA1UdEQQgMB6BHEpvc2UtTWFyY2lvLk1h cnRpbnNAZW5zbXAuZnIwDQYJKoZIhvcNAQEFBQADggIBAIdI9w1oNewSJv/wJ4TQzw8E2w2V AbSN2wj0l7t0GQr8UoJMffNBfDMQNgCdJ1vATh/bIhmHf9imV9Tdo7maoM+R/5KvMuZEhQIj K6sVizsvGHWiWpPjUQE3tSV5dFdVQUlU4It/0JaXGh4EIB2vhmauag550L0amI3mozciywVy 1gT4i8PK0fycJTDm2hhIGlYIMjU7cQUxx3+G3NBKyncFestD+eZL7w6qK2GOaUNVWRtjUHIX 2R0nLCOEQTUkcdQ55vHPbBcUdhCfe9h7Kk5C7p8+NzSgxzhdeSl7+Hj0qEW3THB0wkxBLz7m DL/K0otW6dDpUXVtRFsU+fDACNZ0Rg22gHgBkUVQuj3zMekIBnsjEDi/ImyvDaVwSKDL4IG8 YxePe7tcuUpxH1AiXRw1KVtHc2k24ferQn8sHV8SUynyor2647t55wKojBjBV9flydheOOEg +Hi++kG8pnv7yrKr1rLigQevo9XPIMqLSrpHtB8EBDj3Ps2e2CVICyP9YIaxnXwfYeKpLyo0 shuGp4l2cr6HfohZbMxHBeWOjfYxMDfu860TZb0H2NMR4CTZijj/GO7PIn5a/VEyjwFoCmsX AwxQCdO8zPfIwe44jqSEtzIRQ4/547Tc3ghaYK6IzP1+PdPONTBNBGHqA7e2YYVjLLtfxRpN zr+Jr6zTMYIDhzCCA4MCAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0 cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwHW9zAJBgUrDgMCGgUAoIIB 2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAxMjUyMDM5 MzBaMCMGCSqGSIb3DQEJBDEWBBQLKjRbj+7qBwWcxogZ9YGuDZk5YjBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB 1vcwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB1vcwDQYJKoZIhvcN AQEBBQAEggEAhnyxcEW/cR4Pw9S4XP0c6U746if0a0Kn2hoqJkSAH1KiP7bAMWzxCS14is4x bY0DfPYpZT6Qj/INb+Rz3sHCnc9HBbJua8+skYNVMXk1iWc3+31xcQWBeFkDCBQO2McjewBi Yg13smP+swfbVi5zZlh2xdqRpI9wE5nzdIfLb4QNiO3OCd2zwJOq78i5PlG7JTF1laaZAhsq 8OAhEBla6y4b0J7OdQB/Tzi2NkkBdIZHoss8tUuODm5Z/xmrRbY63Z/MeDae6wbkoBivGxha B5fcvANOOC0tiSlNCn6Kbr/U4qCnDhT+xMdinALSwQBqzBj1mF3XAouqu/HUt9ReOAAAAAAA AA== --------------ms040702080701060306070401-- --------------050500030300040701010603 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ freebsd-threads@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-threads To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" --------------050500030300040701010603-- From owner-freebsd-threads@FreeBSD.ORG Wed Jan 25 22:59:43 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 CA7FC16A420; Wed, 25 Jan 2006 22:59:43 +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 879B443D45; Wed, 25 Jan 2006 22:59:43 +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 14:59:42 -0800 Message-ID: <43D802DF.9040003@elischer.org> Date: Wed, 25 Jan 2006 14:59:43 -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: Jose-Marcio.Martins@ensmp.fr References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> In-Reply-To: <43D7E45E.8070103@ensmp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, 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 22:59:44 -0000 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?). > > 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 > > 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" From owner-freebsd-threads@FreeBSD.ORG Thu Jan 26 08:55:07 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 EE43A16A420; Thu, 26 Jan 2006 08:55:07 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from saci.ensmp.fr (saci.ensmp.fr [194.214.158.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87DBD43D45; Thu, 26 Jan 2006 08:55:07 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from [127.0.0.1] (localhost.ensmp.fr. [127.0.0.1]) by saci.ensmp.fr (sendmail X.1.0.PreAlpha0.0) with ESMTP id S00000000000002D100; Thu, 26 Jan 2006 09:55:05 +0100 Message-ID: <43D88E69.1020102@ensmp.fr> Date: Thu, 26 Jan 2006 09:55:05 +0100 From: Jose Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 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> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, 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: Thu, 26 Jan 2006 08:55:08 -0000 Hello, Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: >>> 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). So, if I understood, the better I can do is, instead of letting the child follow a different path after the fork, he shall better do an exec of another thing and start a clean process... > > 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?). Very clear... Even on releases older than 5.3... 8-( You clarified a bug which was "harassing" me for a very long time... Can you point me a good doc about threads, signals, and such kind of things in FreeBSD context ? Thanks very much for all your very helpful hints. Jose-Marcio From owner-freebsd-threads@FreeBSD.ORG Thu Jan 26 19:28: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 E898116A420; Thu, 26 Jan 2006 19:28: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 3E09B43D7D; Thu, 26 Jan 2006 19:28:22 +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; 26 Jan 2006 11:28:20 -0800 Message-ID: <43D922D5.1000307@elischer.org> Date: Thu, 26 Jan 2006 11:28:21 -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: Jose Marcio Martins da Cruz References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr> In-Reply-To: <43D88E69.1020102@ensmp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, 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: Thu, 26 Jan 2006 19:28:43 -0000 Jose Marcio Martins da Cruz wrote: >Hello, > >Julian Elischer wrote: > > >>Jose Marcio Martins da Cruz wrote: >> >> > > > >>>>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). >> >> > >So, if I understood, the better I can do is, instead of letting the child follow >a different path after the fork, he shall better do an exec of another thing and >start a clean process... > > > often what is done is to exec itself again with a different argument to make it know it is the child. why do you need to fork? why not just use more threads? >>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?). >> >> > >Very clear... Even on releases older than 5.3... 8-( > >You clarified a bug which was "harassing" me for a very long time... > >Can you point me a good doc about threads, signals, and such kind of things in >FreeBSD context ? > > I can suggest the threads programming book Programming with POSIX Threads by David R. Butenhof He was the main person behind the posix threads anyhow so he's pretty authoratative. >Thanks very much for all your very helpful hints. > >Jose-Marcio > >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > From owner-freebsd-threads@FreeBSD.ORG Thu Jan 26 19:32:19 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 6CECD16A420; Thu, 26 Jan 2006 19:32:19 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A2143D6E; Thu, 26 Jan 2006 19:32:18 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 6E5455E48EC; Thu, 26 Jan 2006 11:32:18 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id F36F85E48D3; Thu, 26 Jan 2006 11:32:12 -0800 (PST) In-Reply-To: <43D88E69.1020102@ensmp.fr> References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Thu, 26 Jan 2006 11:32:08 -0800 To: Jose Marcio Martins da Cruz X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-hackers@freebsd.org, Julian Elischer , 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: Thu, 26 Jan 2006 19:32:19 -0000 On Jan 26, 2006, at 12:55 AM, Jose Marcio Martins da Cruz wrote: > Can you point me a good doc about threads, signals, and such kind > of things in > FreeBSD context ? David Butenhof's book, "Programming with POSIX Threads", includes a good discussion of signals in the context of pthreads. How to avoid the problems you have been experiencing is covered in that book. If you haven't read the book, I highly recommend that you do so. Jason From owner-freebsd-threads@FreeBSD.ORG Thu Jan 26 20:43:10 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 2EB7516A420; Thu, 26 Jan 2006 20:43:10 +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 E1D5343D45; Thu, 26 Jan 2006 20:43:09 +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; 26 Jan 2006 12:43:09 -0800 Message-ID: <43D9345D.9010205@elischer.org> Date: Thu, 26 Jan 2006 12:43:09 -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: Jose-Marcio.Martins@ensmp.fr References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr> <43D922D5.1000307@elischer.org> <43D9324A.40905@ensmp.fr> In-Reply-To: <43D9324A.40905@ensmp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, 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: Thu, 26 Jan 2006 20:43:10 -0000 Jose Marcio Martins da Cruz wrote: > Julian Elischer wrote: > >> Jose Marcio Martins da Cruz wrote: > > >>> So, if I understood, the better I can do is, instead of letting the >>> child follow >>> a different path after the fork, he shall better do an exec of >>> another thing and >>> start a clean process... >>> >>> >>> >> >> often what is done is to exec itself again with a different argument >> to make it know it is the child. >> >> why do you need to fork? why not just use more threads? > > > This is a security issue. The application is a sendmail mail filter. > For many reasons the filter may die : an attack may succeed or there > may be a bug. > > The father is a supervisor only. He launches the child which is the > real filter. From time to time, the father checks if the filter is > alive and running (not blocked) - this is done by a non blocking wait > and a pipe between the father and the child. If there is a problem > with the child (died of blocked), the father does some clean up and > launches a fresh child. sounds like the parent need not be threaded yet. > > I use a different process instead of more threads because a problem > with a thread can compromise all the process. > > This application runs fine under Solaris (four years long now). Each implementation has different side-effects On FreeBSD 6, try the libthr() threading library. > > Well, I definitely shall try to change this architecture, at least for > FreeBSD and maybe Linux too. > >> >> I can suggest the threads programming book >> Programming with POSIX Threads >> by >> David R. Butenhof > > > Thanks, I have it. I read it long time ago... > > > From owner-freebsd-threads@FreeBSD.ORG Sat Jan 28 01:40:07 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED66E16A420 for ; Sat, 28 Jan 2006 01:40:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A886D43D48 for ; Sat, 28 Jan 2006 01:40:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0S1e7pR057577 for ; Sat, 28 Jan 2006 01:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0S1e7BU057576; Sat, 28 Jan 2006 01:40:07 GMT (envelope-from gnats) Date: Sat, 28 Jan 2006 01:40:07 GMT Message-Id: <200601280140.k0S1e7BU057576@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: "Lee, Joseph" Cc: Subject: Re: threads/91779: threaded perl-5.8's io/pipe test and IPC::Run::start() stalls in umtx with libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Lee, Joseph" List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 01:40:08 -0000 The following reply was made to PR threads/91779; it has been noted by GNATS. From: "Lee, Joseph" To: Cc: Subject: Re: threads/91779: threaded perl-5.8's io/pipe test and IPC::Run::start() stalls in umtx with libthr Date: Fri, 27 Jan 2006 17:33:28 -0800 Verified that MFCs of -CURRENT changes for libthr and the kernel into 6-STABLE fixes the stalls for threaded perl and pipes. Thanks! ______________________________________ Joseph Lee (joseph.lee@disney.com) Release Manager Walt Disney Internet Group VR Studio