From owner-freebsd-hackers  Sun Jul  6 22:00:07 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id WAA24034
          for hackers-outgoing; Sun, 6 Jul 1997 22:00:07 -0700 (PDT)
Received: from lister.bogon.net (0@gw.bogon.net [204.137.132.49])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24029
          for <hackers@freebsd.org>; Sun, 6 Jul 1997 22:00:04 -0700 (PDT)
Received: from kryten.bogon.net (500@kryten.bogon.net [204.137.132.58])
	by lister.bogon.net (8.8.5/8.8.5) with ESMTP id WAA09109
	for <hackers@freebsd.org>; Sun, 6 Jul 1997 22:00:01 -0700 (PDT)
From: Wes Santee <wes@bogon.net>
Received: (from wes@localhost)
	by kryten.bogon.net (8.8.6/8.8.5) id VAA05316
	for hackers@freebsd.org; Sun, 6 Jul 1997 21:59:58 -0700 (PDT)
Message-Id: <199707070459.VAA05316@kryten.bogon.net>
Subject: Is there a thread-happy recv()?
To: hackers@freebsd.org
Date: Sun, 6 Jul 1997 21:59:58 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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                                                )