lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #10088] Correctly implement close() vs. shutdown()


From: Jeff Barber
Subject: [lwip-devel] [task #10088] Correctly implement close() vs. shutdown()
Date: Mon, 22 Feb 2010 18:25:16 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6

Follow-up Comment #19, task #10088 (project lwip):

Not sure exactly what you're seeing in Stevens (I don't have a copy of that -
can only see what google books allows).  I do see a couple of differences with
the socket API between close() and shutdown(SHUT_RDWR):

1. Clearly, with the socket API, the lifetime of the "socket" must not end
until the close has been performed since the API should distinguish between
'illegal file descriptor' and 'valid file descriptor but socket now closed'. 
(For example, one should be able to call read/recv on a shutdown(RD) socket
and get a zero return as opposed to -1/EBADF.)

2. Unix systems typically implement some differences in close() related to
the SO_LINGER socket option.  Not sure that lwip would ever want to implement
that though.

3. A unix system would also introduce the possibility that the same file
descriptor is shared either in the same process (via dup(2)) or in different
processes via inheritance.  That would not seem to apply to lwip though.

Assuming that you do not support (2) and (3), I can't see any difference
between shutdown(RDWR) and close except for (1).  And it seems to me that the
*underlying pcb* need not hang around after a shutdown(RDWR) any more so than
close().  The application would not be able to affect or be affected by the
session anyway.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?10088>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]