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 Tue, Oct 29, 2002 at 08:02:03PM +0000, Bart Veer wrote:

>>> It should not cause a panic. Either the write should succeed,
>>> or it should return an err code saying the file is closed.
>>> These operations should be atomic with respect to each other.
> 
> Grant> Agreed.  
> 
> I am not so sure.
> 
> If I understand the scenario correctly, the current code does
> something like:
> 
>   thread a: close(socket_fd);
>   thread b: write(socket_fd, buf, size);

That's the way it's been described to me.

> Now imagine:
> 
>   thread c: new_fd = accept(server_socket);
> 
> (calls to connect() or open() would have similar problems).
> Depending on what gets scheduled when, the write() may send
> some or all of the data out of the first socket, or it may fail
> with an error code, or it may write the data to a completely
> different socket that happens to reuse the file descriptor and
> cause all kinds of chaos.

IMO, that's fine.  Calling write() on a valid, writable fd
should write data. If it's not a valid fd write() should return
an error.  I don't think that panicking is the best choice.

> Or, with the particular stack being used, the system panics.
> Depending on the application, writing strange data to a random
> socket could be a lot more damaging than a panic.

True.  But, but the stack has no way to know if a write() call
on a valid fd is sending data out the "correct" socket or not,
so how do you decide when to panic? If the write() call is on
an invalid fd, why panic rather than returning a meaningful
error?

> The current application code appears fatally flawed and must be
> fixed. A socket is a shared resource, it should only be
> manipulated by one thread at a time.

I think that having one thread reading a socket and a second
one writing a socket should be allowed (and should work). The
case in my original post (close/write) is definitely dodgy
though.

> If the application is fixed then there is no need to worry
> about extra locking in the TCP/IP stack, at least not for this
> problem.

Unless there are other cases that really should work that
don't: like one thread reading and one thread writing [IIRC
that is the one that I found/fixed way back when].

IMO, an embedded OS should only panic if there's absolutely
nothing else to do and no way to avoid the situation.

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