Date: Sat, 2 Feb 2002 22:07:42 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: roam@FreeBSD.org Cc: yxpan@yahoo.com, freebsd-bugs@FreeBSD.org Subject: Re: i386/34536: accept() blocks other threads Message-ID: <20020202220742.GA14170@walton.maths.tcd.ie> In-Reply-To: <200202021604.g12G4Fc77225@freefall.freebsd.org> References: <200202021604.g12G4Fc77225@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
David.
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?20020202220742.GA14170>