Cancel read on socket

[Joel Sherrill]

Chris Johns wrote:
> 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?
>>
>>     

Let's see if we can agree on one POSIX defined case and work from
there.  Going from Apple's recommendations on interrupting/canceling
socket reads and trying to make that work on RTEMS.

POSIX read() defines at least one "interruption/cancel" statuses that
we currently have no way to return.  See
http://www.opengroup.org/onlinepubs/000095399/functions/read.html

[EINTR] The read operation was terminated due to the receipt of
a signal, and no data was transferred.

Even when POSIX is enabled, pthread_kill() sent to a thread blocked
on a read() will not get an EINTR. 

All RTEMS IO calls are built upon Classic API manager calls which
have non-interruptible blocking calls.  There would have to be a way
to interrupt one of these calls and propagate it back through the
normal read() code.

The first possibility I had were to add a rtems_cancel_blocking_operation
which could take a thread id easily or an object id (harder to implement)
and let a special status indicate that it was interrupted.

Another alternative was to be able to create Classic API semaphores
that are signal interruptible and have a way to generate a "signal" in
the Classic API since pthread_kill() would be the only defined way
to interrupt the operation.

Either possibility needs working out.  The crux of the problem logically
is how to generate the EINTR signal when POSIX is disabled and how to
get pthread_kill() to interrupt what is defined as a non-interruptible
in the Classic API. 

I hope this makes sense.  We should support a way to get EINTR from
a blocking read() and right now, there isn't.  And the mechanism should
work independent of RTEMS configuration.

>>> 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.
>
>   
I didn't realize ECANCELED only applies to aio and lio. Those are too
complicated for this simple of a problem.

We just need to support getting EINTR back from a read like POSIX
requires.

> Regards
> Chris
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985