Cancel read on socket
Chris Johns
chrisj at rtems.org
Thu May 29 02:53:36 UTC 2008
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:
http://www.opengroup.org/onlinepubs/009695399/functions/aio_cancel.html
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.
Regards
Chris
More information about the users
mailing list