On Thu. 21 Jul. 2022 at 16:36, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
> On 21.07.22 04:37, Vincent Mailhol wrote:
> > On Wed. 21 Jul. 2022 at 01:43, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
> >> On 19.07.22 17:16, Vincent Mailhol wrote:
> >>> On Tue 19 Jul. 2022 at 23:38, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
(...)
> I just wanted to get an impression whether it is handy to program this
> extended API or not.
>
> >> nbytes = read(s, &can.xl, sizeof(struct canxl_frame));
> >> if (nbytes < 0) {
> >> perror("read");
> >> return 1;
> >> }
> >> printf("nbytes = %d\n", nbytes);
> >
> > Does read() guarantee atomicity? From "man 2 read":
> > | It is not an error if [the return value] is smaller than the number
> > | of bytes requested; this may happen for example because fewer bytes
> > | are actually available right now (maybe because we were close to
> > | end-of-file, or because we are reading from a pipe, or from a
> > | terminal), *or because read() was interrupted by a signal*.
> >
> > I think the answer is yes, but I prefer to double check (I am
> > especially concerned by the signal interrupts).
>
> Hm, we are not reading from a file but from a socket here that provide
> chunks in the form of struct can_frame in raw_recvmsg(). You only get a
> MSG_TRUNC there when you provide a (buffer)size in userspace that's to
> small.
>
> I've never got any error reports on CAN_RAW reading (over 16 years) and
> all the examples contain a test for sizeof(struct can_frame) like this:
>
> >> if (nbytes != sizeof(struct can_frame) &&
> >> nbytes != sizeof(struct canfd_frame)) {
>
> So we either have an error or an incomplete CAN frame which becomes an
> error too.
>
> Do you think this is still worth an investigation?
My concern is whether or not read() can really be interrupted by a signal?
But actually, even if read() were not atomic, it would still be
usable: you just have to continue reading until you get the first 64
bits, then you have all the information needed to determine the type
and the total length.
So I do not think this is a valid concern, but even if it is, it does
not invalidate current design. So OK to move on. Maybe it is just
something to add to the TODO list of the "things I yet have to
understand".
Yours sincerely,
Vincent Mailhol
