Adding RTEMS_INTERRUPTED

[Joel Sherrill]

On Fri, Oct 4, 2019 at 1:53 PM Peter Dufault <dufault at hda.com> wrote:

>
>
> > On Oct 4, 2019, at 14:04 , Joel Sherrill <joel at rtems.org> wrote:
> >
> > Hi
> >
> > I am now looking at the second phase of processing <ctl>-C to generate
> SIGINTR is
> > to have read() return -1/EINTR. I want to specifically add this support
> to termios
> > although I think other file types would have to address this
> independently,
> >
> > For termios, we need rtems_deviceio_read() to return -1/EINTR but it
> returns -1/errno
> > based on rtems_status_code from rtems_io_read(). The issue is that we
> don't have
> > anything that maps to EINTR in the rtems_status_code enumeration.
> >
> > Is there any objection to adding RTEMS_INTERRUPTED as a status code?
> >
> > I am open to suggestions for a better name.
> >
>
> Do you see a use for RTEMS_INTERRUPTED instead of to support EINTR defined
> behavior?  If you don't I'd name it RTEMS_EINTR so that it isn't overloaded.
>

I don't see if being used for any other purpose. I don't even expect it to
be returned from
a directive such that a user would have to process it. That makes
RTEMS_EINTR  a good
candidate.

I don't see that there are many places that use Classic API status which
would allow interruption.

In general, on the POSIX operation side there may be more operations which
are interruptible
by the standard. We have interruptible blocking states but it all depends
on how the operation
is constructed if it isn't a threading/concurrency primitive.

--joel

>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191004/316b2fc7/attachment.html>