Date: Sun, 6 Jul 1997 21:59:58 -0700 (PDT) From: Wes Santee <wes@bogon.net> To: hackers@freebsd.org Subject: Is there a thread-happy recv()? Message-ID: <199707070459.VAA05316@kryten.bogon.net>
next in thread | raw e-mail | index | archive | help
Hi all. I noticed in a chunk of code I'm writing that a blocking call
to recv() is putting the entire process to sleep such that even the
other threads in the process are blocked from executing. I'm linking
against libc_r (2.2-STABLE cvsup'd July 3rd) right now, is there
anything else I should be doing to stop recv() (or any blocking call
for that matter) from suspending the entire process?
Here's a more detailed explanation. I've got two threads, T1 and T2.
Here's what they do:
T1 T2
-- --
1) Issue blocking recv on a socket Acquire mutex
2) Acquire mutex after recv returns Wait for condition (which unlocks mutex)
3) Do something with data Do something with data (mutex reaquired)
4) Unlock mutex Unlock Mutex
5) Signal a conditional in T2 Loop back to 1
6) Loop back to 1
What I'm seeing is that while T2 is doing step 3, T1 is doing step 1.
Then when T2 does step 4, it blocks while trying to unlock the mutex!
Both T1 and T2 try to acquire the same mutex, of course.
At first I thought this shouldn't be possible, but I set up another
test where no blocking calls are issued in either thread ('cept for
the pthread calls themselves), and everything worked just fine.
Any pointers to why this wouldn't be working (including what the state
of user-process threads is in 2.2-STABLE) is appreciated.
Cheers,
--
( Wes Santee PGP: e-mail w/Subject: "Send PGP Key" )
( mailto:wes@bogon.net )
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707070459.VAA05316>