[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cancel read on socket
- Date: Thu, 29 May 2008 12:53:36 +1000
- From: chrisj at rtems.org (Chris Johns)
- Subject: Cancel read on socket
Leon Pollak wrote:
> On Wednesday, 28 ?May 2008, Ralf Corsepius wrote:
>> On Wed, 2008-05-28 at 09:22 +0300, Leon Pollak wrote:
>>> On Wednesday, 28 ?May 2008, Chris Johns wrote:
>>>> Joel Sherrill wrote:
>>>>> Without thinking about compatibility at all, shouldn't it be
>>>>> possible to add an RTEMS specific IOCTL which forced
>>>>> a read() to return an error like ECANCELED?
>> Think along these lines from POSIX:
>> If a read() is interrupted by a signal before it reads any data, it
>> shall return -1 with errno set to [EINTR].
>> If a read() is interrupted by a signal after it has successfully read
>> some data, it shall return the number of bytes read.
>> How would you handle canceling io?
> Well, IMHO, this is simple - as I asked to cancel this io its results are not
> interesting for me even if there was already some data received.
> And, BTW, what is the principal difference between this and the timeout case?
> I mean, that timeout occurred exactly before the data arrived?
>> In addition to that, I am opposed to adding anything proprietary to a
>> standardized API.
> Here is the good point.
> And I should not speak about this, if there was no precedent - CancelIo in
> Windows. Yes, I don't like MS at all, but they did it much later then
> Berkley/BSD - still may be they already saw this need...:-)
There is the AIO API which is an optional part of the standard:
This does not lower the complexities of implementing a cancel how-ever it does
provide a suitable standard for RTEMS to adopt. To give you an idea of the
complexity a file system fd is not the same as a socket fd. This is why select
only works on socket fds.