unlocking the recv

unlocking the recv

[Grzegorz Dwornicki]

Hello

I am wondering with pure theoretical task. Is there a posibility to
unlock the recv function without making the socket nonblocking? Lets
assume that we have our server and client:

server <---network ---> client

Server callend the recv function and waits for the data from client
soo its blocked in wait_queue. The socket is in nonblocking state. Can
this proces/thread be unblocked on demand?

unlocking the recv

[Jeff Haran]

>-----Original Message-----
From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-
>bounces at kernelnewbies.org] On Behalf Of Grzegorz Dwornicki
>Sent: Wednesday, June 03, 2015 3:42 AM
>To: kernelnewbies at kernelnewbies.org
>Subject: unlocking the recv
>
>Hello
>
>I am wondering with pure theoretical task. Is there a posibility to unlock the
>recv function without making the socket nonblocking? Lets assume that we
>have our server and client:
>
>server <---network ---> client
>
>Server callend the recv function and waits for the data from client soo its
>blocked in wait_queue. The socket is in nonblocking state. Can this
>proces/thread be unblocked on demand?

I would think that sending it a signal would work.

Jeff Haran

unlocking the recv

[Valdis.Kletnieks at vt.edu]

On Wed, 03 Jun 2015 12:42:28 +0200, Grzegorz Dwornicki said:

> Server callend the recv function and waits for the data from client
> soo its blocked in wait_queue. The socket is in nonblocking state. Can
> this proces/thread be unblocked on demand?

Umm... according to the manpage for 'man 2 recv':

       If no messages are available at the socket, the receive calls  wait  for  a  message  to  arrive,
       unless  the  socket is nonblocking (see fcntl(2)), in which case the value -1 is returned and the
       external variable errno is set to EAGAIN or EWOULDBLOCK.  The receive calls normally  return  any
       data  available,  up  to the requested amount, rather than waiting for receipt of the full amount
       requested.

So if the socket really *is* nonblocking, I'm not seeing how it would end
up blocked.  If it sits in that state for long enough, you might want to do
a 'cat /proc/NNN/stack' to see where in the kernel it is.

But first, I'd double check that the socket is in fact non-blocking. Did
you remember to do something like this:

    rc = socket(AF_INET,SOCK_whatever|SOCK_NONBLOCK,protocol);
    if (rc < 0) { /* whine about failure */ };