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