"Nick" == Nick Garnett <nickg@ecoscentric.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.