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?


Bart Veer <bartv@ecoscentric.com> writes:

> I agree that one thread reading/another thread writing should work.
> But I believe the system's behaviour for a concurrent write/close is
> undefined, i.e.
> 
>    thread A: close(socket_fd);
>    thread B: write(socket_fd, buf, size);
> 
> is basically equivalent to:
> 
>    thread A: free(some_buffer);
>    thread B: memcpy(some_buffer, elsewhere, many_kilobytes);
> 
> Any application which attempts the latter is fundamentally broken.
> Sometimes you can get away with it, sometimes the system will crash.
> You would not blame the memory allocation package when a crash occurs.
> 
> Similarly the concurrent write/close is fundamentally broken.
> Sometimes the application can get away with it, sometimes you will get
> sensible error codes, sometimes the system will crash - in this case,
> raise a panic. The fault is with the application developer, not with
> the TCP/IP stack. Admittedly more programmers will have experience
> with memory corruption bugs than with the subtleties of socket
> programming.

This is not really an application problem -- there's nothing wrong
about an application expecting this to work. Socket calls should, as
as has already been pointed out elsewhere, be atomic with respect to
eachother. In the scenario that we are considering, either the close
happens first, in which case the write will return an error; or the
write will happen first, in which case the close will flush the data
and successfully close the stream.

I can see plenty of situations where closing a socket from another
thread is a legitimate response to some error situation. Although I
would hope that a well behaved program would normally shut a stream
down in a more controlled manner.

> 
> Adding more assert's to the TCP/IP stack to catch such problems during
> development is fine, because those do not add any overhead to the
> production system. Adding lots of locking or additional run-time tests
> to work around bugs in some applications is much less acceptable. In
> my opinion anyway.

I would contend that the locking regime in the TCP/IP stack is at
present not right and needs to be fixed.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.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]