From owner-freebsd-bugs Sat Feb 2 14:15:43 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 5257F37B416; Sat, 2 Feb 2002 14:15:36 -0800 (PST) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id g12MFPO6040486; Sun, 3 Feb 2002 01:15:26 +0300 (MSK) Date: Sun, 3 Feb 2002 01:15:23 +0300 (MSK) From: Maxim Konovalov To: David Malone Cc: roam@FreeBSD.ORG, , Subject: Re: i386/34536: accept() blocks other threads In-Reply-To: <20020202220742.GA14170@walton.maths.tcd.ie> Message-ID: <20020203011345.G59736-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 22:07-0000, Feb 2, 2002, David Malone wrote: > On Sat, Feb 02, 2002 at 08:04:15AM -0800, roam@FreeBSD.org wrote: > > Synopsis: accept() blocks other threads > > > > State-Changed-From-To: open->closed > > State-Changed-By: roam > > State-Changed-When: Sat Feb 2 07:59:14 PST 2002 > > State-Changed-Why: > > accept(2) is documented as a blocking syscall. In FreeBSD's current > > threads implementation, blocking syscalls block the whole process - all > > of its threads. The possible ways around that are: using the > > linuxthreads port, waiting for FreeBSD 5.0's KSE's, or using > > non-blocking sockets and select(2) as described in the PR. > > Surely this can't be a valid explaination for the problem? Syscalls > like select, wait4 and read are documented to block, but libc_r > provides magic versions which only block the current thread. I note > a version of accept is included in libc_r. I'd guess that one of > the following has happened: > > 1) the POSIX threads spec says that accept should block, > 2) there is a bug in the libc_r version of accept, > 3) there is a bug in the code using accept. > > I honestly don't know much about POSIX threads, but I'd guess that > (3) is a possibility 'cos sockets are created in the example code > before the threads system is initialised, which might mean that the > socket is getting created with incorrect settings of some sort. > > (I do note that Sheldon closed a PR recently with a similar reason, > but the function in question was msgrcv(3), which might be hard to > produce a non-blocking version of within libc_r because I don't > think you can poll(2) on message queue and I think libc_r uses poll > to do things in a non-blocking way.) > > If I'm miles off here, please correct me... I believe you are correct, David, and we have to reopen this PR. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message