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