Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Sep 1998 17:59:55 -0400 (EDT)
From:      HighWind Software Information <info@highwind.com>
To:        rotel@indigo.ie
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: Thread Problems
Message-ID:  <199809072159.RAA03933@highwind.com>
In-Reply-To: <199809072147.WAA00873@indigo.ie> (message from Niall Smart on Mon, 7 Sep 1998 22:47:17 %2B0000)

next in thread | previous in thread | raw e-mail | index | archive | help

   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)

Sounds good. Does it use signals to do anything interesting?
I'm wondering if perhaps there is some memory corruption.

   > 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.

Not funny at all. Somebody is calling select() to "sleep" for a few
seconds.

   [ 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.

It came from accept(). Somebody was blocked in accept(). I don't know why
we don't see the return from accept() that produced that fd.

   Can you provide a more comprehensive ktrace?

I'll work on it. Any tips on what flags to ktrace?

-Rob

ps.
	I applied the patches from PR 7744. Still no better.

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?199809072159.RAA03933>