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: simultaneous socket write/close causes panic?


On Thu, Oct 31, 2002 at 10:06:36PM +0000, Bart Veer wrote:

>     Nick> be atomic with respect to eachother. In the scenario that we
>     Nick> are considering, either the close happens first, in which
>     Nick> case the write will return an error; or the write will
>     Nick> happen first, in which case the close will flush the data
>     Nick> and successfully close the stream.
> 
> It is an application problem because a third thread may cause the file
> descriptor to be reallocated, e.g. by a concurrent call to connect()
> or accept(). So you could end up with the sequence
> close()/accept()/write() and the data going to some random
> destination.

Correct.  That's perfectly fine.  Nobody is complaining about that or asking
that eCos prevent that.  That's completely different (and IMO, way better)
than having the stack cause a panic and shut down the entire system.

> No amount of locking within eCos can prevent this, it has
> to be addressed at the application level.

Agreed.  Nobody is suggesting that the kernel or stack should try to address
that problem.  What I would like to see is that the stack not panic.

>     Nick> I can see plenty of situations where closing a socket from
>     Nick> another thread is a legitimate response to some error
>     Nick> situation. Although I would hope that a well behaved program
>     Nick> would normally shut a stream down in a more controlled
>     Nick> manner.
> 
> I agree that there are such situations, but I don't believe close() is
> the right tool for the job here. Instead the code that detects the
> error condition should call shutdown() with SHUT_RDWR. I think (but
> have not verified) that should abort any concurrent read() or write()
> calls, and cause subsequent calls to fail. Then when all threads using
> the socket are aware of the error condition and will no longer attempt
> communication via the file descriptor, then the close() can happen
> safely.

That certainly sounds like a better solution from an application point of
view.  


However, since the mutex mechanism has to be there to make sure the stack
doesn't panic for simultaneous read/write/shutdown/ioctl calls, why not make
it avoid the panic for a simultaneous close also?  It's not like close is
called so often that we have to shave 10us off at the risk of a system
panic.

-- 
Grant Edwards
grante@visi.com

-- 
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]