This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
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