From owner-freebsd-hackers Sat Jan 30 15:47:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06698 for freebsd-hackers-outgoing; Sat, 30 Jan 1999 15:47:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06684 for ; Sat, 30 Jan 1999 15:47:13 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA08024; Sat, 30 Jan 1999 16:47:07 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd007986; Sat Jan 30 16:47:02 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id QAA24966; Sat, 30 Jan 1999 16:46:45 -0700 (MST) From: Terry Lambert Message-Id: <199901302346.QAA24966@usr04.primenet.com> Subject: Re: select and threads again To: ks@itp.ac.ru (Sergey S. Kosyakov) Date: Sat, 30 Jan 1999 23:46:45 +0000 (GMT) Cc: jb@cimlogic.com.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Sergey S. Kosyakov" at Jan 29, 99 04:59:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Finally I found why select hangs. In multithread mode ILU uses pipe() > for "communicational channel" between threads. So each select actually is > waiting on two FD - first is the socket and second is the pipe. I don't know > why in that situation select hangs forever. If I force select to wait only on > single socket, then it works. I guess there are still some restrictions for > select in multithread environment. The real non-libc_r wrapped select is supposed to be called by the wrapping select using a zero valued timeval struct (effecting a "poll") when there are other threads ready to run. When all threads are blocked pending I/O on fd's, then a real select is called on all of the fd's on which I/O is pending with a NULL pointer instead of a zero valued timeval struct. This makes the select hang until I/O is available on one or more of the fd's. If you are getting a blocking select, then the only possible cause is that the scheduler believes that there are no other threads in a read-to-run state, and therefore makes the blocking call instead of call converting it to a polling call which, if not input is pending, is followed by a threads context switch. Perhaps you are both read and write selecting the pipe fd, in two seperate threads? In general, write selecting is a bad idea. This may be a problem in the pipe code, or in the wrapping function in libc_r (unlikely). You could try using a POSIX domain socket instead of a pipe; it uses the same underlying code (man socketpair). If this also hangs, try using a real socket (AF_INET instead of AF_UNIX). Also, make sure you are not using fork(), since it interacts badly with threads. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message