Closing a socket.
Till Straumann
strauman at slac.stanford.edu
Mon May 23 23:58:45 UTC 2005
Chris Johns wrote:
> Chris Johns wrote:
>
>>
>> See PR785. I have detailed the problem.
>>
>
> I have attached patches to the PR that fix the problem. I would like
> get some feedback and review comments on patches before committing them.
Hard to track all that stuff :-(
I really don't have time to do a detailed, careful analysis although IMO
it would be important.
A quick look at the 4.6. patch leaves these questions:
a) Not sure this is OK:
sc = rtems_bsdnet_event_receive(xxx, &events)
if ( events & XXX )
do_something();
Is 'events' valid even if the return status is not successful?
b) soconnwakeup():
SOCONNABORTED is only sent to socket in SO_ACCEPTCONN state.
I believe this will not interrupt 'connect()' where it loops
soconnsleep()ing
for a connection.
c) Is this (in 'connect()')
+/*
+ * chrisj at rtems.org: removed the clearing of the SS_ISCONNECTING so
+ *
removal still necessary? I thought the closing thread is put to sleep
(and can only run again after 'connect' releases the network
semaphore).
d) I'm not sure how to deal with soconnsleep() called from soclose()
(SO_LINGER path). I believe that in this case, the closing thread
should *not* receive a CONNABORT event as it probably currently
would.
Also, there is probably a chance for two threads trying to
soconnsleep() on the same socket: accept()ing thread A
and closing thread B (again, if SO_LINGER).
Also, I believe that soconnsleep() needs to implement the SO_LINGER
timeout, something that even the old implementation failed to do.
Thanks for the great work
--Till
>
> I have tested 4.6-branch and 4.7.
>
More information about the users
mailing list