This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TCP close(...) action


On Sat, Oct 18, 2003 at 11:24:40AM -0700, Matt Jerdonek wrote:
> Hi Folks,
> 
> I have a simple program with two threads that send /
> recv from a single TCP socket.  One thread blocks on a
> recv call while the other thread sends data on the
> same socket.
> 
> I put a close call in the send thread.  The expected
> behavior was for the recv thread to wake (with 0 bytes
> of data) and a FIN to be sent on the ethernet.  The
> actual behavior was that the recv thread never woke
> and the FIN was not sent.  (Is this intended or a
> bug?).  I found the soclose function would not be
> invoked because the recv was still using the file
> handle.  Once the recv released the file handle, the
> FIN flowed on the ethernet.
> 
> I worked around this issue by calling
> cyg_thread_release from my application, which woke up
> the recv thread.  But I wonder if there is better
> solution?  Could (or should) the close call be made to
> wake up blocked threads?  If so, any suggestions?

I think what its currently doing is at least sensible. Should close
cause other calls using the socket to fail and return an error? What
error should it return? To answer these questions i think you need to
look at the standards and see what other multithreaded OS's do in the
same situation. If you re-write your test program to use POSIX
threads, it should then be possible to run it on linux, SunOS, *BSD
etc. We can then decide if this is right or wrong.

     Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]