Date: Sat, 30 Jan 1999 23:46:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ks@itp.ac.ru (Sergey S. Kosyakov) Cc: jb@cimlogic.com.au, freebsd-hackers@FreeBSD.ORG Subject: Re: select and threads again Message-ID: <199901302346.QAA24966@usr04.primenet.com> In-Reply-To: <XFMail.990129165940.ks@itp.ac.ru> from "Sergey S. Kosyakov" at Jan 29, 99 04:59:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901302346.QAA24966>