Date: Mon, 7 Sep 1998 22:47:17 +0000 From: Niall Smart <rotel@indigo.ie> To: HighWind Software Information <info@highwind.com>, freebsd-current@FreeBSD.ORG Subject: Re: Thread Problems Message-ID: <199809072147.WAA00873@indigo.ie> In-Reply-To: <199809070646.CAA01061@highwind.com>; HighWind Software Information <info@highwind.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 7, 2:46am, HighWind Software Information wrote: } Subject: Thread Problems > > Here at HighWind we are trying (really hard) to get our products to > work under FreeBSD. We tried v2.2.X and failed. Now, we are trying 3.0 > and also failing. > > Currently the situation is as follows, on startup, our application > starts a number of threads (via pthread_create). One calls "accept()", > others go off and do lots of "mmap()"'s to files and do other stuff to > various files on the local disk. Firstly let me explain how I think FreeBSD's thread library currently handles I/O, I'm sure I'll be corrected if I get it wrong 8) - all potentially blocking operations are converted where possible to non-blocking operations by setting O_NONBLOCK on the file descriptor. - a select is performed on all file descriptors when ever a (I/O?) syscall is made (i.e., scheduling is co-operative - am I correct here?), if any of the file descriptors are ready then the threads which wished to perform an I/O operation is placed on the thread scheduler's runnable queue, then the scheduling algorithm is started. So, in your case, the listening socket would have O_NONBLOCK set and be entered in a set of file descriptors passed to select for read testing whenever the opportunity arises, when the descriptor becomes readable then the thread is placed on the schedulers runnable queue so when scheduled it can perform the non blocking accept, in the meantime those other threads run doing their mmap() thing. > After the first accept() comes in, the application appears to become > unresponsive. That is, the other threads make no progress. Check out > the ktrace: > [snip mmap activity] > > Good stuff up to here... We are about to get a connection... > > 21620 typhoond CALL gettimeofday(0x19dc30,0) > 21620 typhoond RET gettimeofday 0 > 21620 typhoond CALL select(0,0x19dc78,0x19dcf8,0x19dd78,0x19dc64) > 21620 typhoond RET select 0 This looks funny, I presume this select is being performed by the threads library and not by you, is that the case? If it is then I don't see why the first argument to select is a 0. [ some socket activity ] > 21620 typhoond CALL writev(0x35,0x10ae50,0x5) > 21620 typhoond GIO fd 53 wrote 70 bytes > "400 System starting up - Try again in a few minutes (Typhoon v1.1.7)\r > " > 21620 typhoond RET writev 70/0x46 > 21620 typhoond CALL fstat(0x35,0x10af38) > 21620 typhoond RET fstat 0 > 21620 typhoond CALL close(0x35) > 21620 typhoond RET close 0 > > > Okay, we told that connection to go away. We'd expect to return to work. Ok, so where did descriptor 0x35 come from? I didn't see a call to accept in the above trace. > 21620 typhoond CALL accept(0x6,0x10afd8,0x10afd4) > > That is it. The application SITS idle right here. Doing NOTHING. It > will respond to additional connections. So, it appears that the > "accept()" thread is still responsive. However, all other threads are > not responsive. Can you provide a more comprehensive ktrace? Niall -- Niall Smart, rotel@indigo.ie. Amaze your friends and annoy your enemies: echo '#define if(x) if (!(x))' >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809072147.WAA00873>