[ECOS] simultaneous socket write/close causes panic?
Mon Nov 4 21:17:00 GMT 2002
Bart Veer wrote:
>>>>>>"Nick" == Nick Garnett <email@example.com> writes:
> Nick> This is not really an application problem -- there's nothing
> Nick> wrong about an application expecting this to work. Socket
> Nick> calls should, as as has already been pointed out elsewhere,
> 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. No amount of locking within eCos can prevent this, it has
> to be addressed at the application level.
Just to summarise: the application is almost certainly broken because it
shouldn't do stuff like this because the socket fd number may be
reallocated (modulo micromanagement of the code so you could guarantee
that it wouldn't be). The stack is *also* broken as it shouldn't panic.
Nick Garnett wrote:
> I would contend that the locking regime in the TCP/IP stack is at
> present not right and needs to be fixed.
Potentially, or more accurately Grant should use the new FreeBSD stack :-).
Anyway, Hugo did a lot of work in this area at one point. Grant, you said
the code was from an eCos and net snapshot from Jan 2001. Even so, does it
definitely have this change:
2000-09-01 Hugo Tyson <firstname.lastname@example.org>
* OVERVIEW: This is part of the change to the network stack to
eCosCentric http://www.eCosCentric.com/ <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss