supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* ftrig pipe naming convention
@ 2022-09-18 15:41 Ihor Antonov
  2022-09-18 20:38 ` Laurent Bercot
  0 siblings, 1 reply; 3+ messages in thread
From: Ihor Antonov @ 2022-09-18 15:41 UTC (permalink / raw)
  To: supervision

Hello

As I was playing with s6 I found out that not every fifo placed in
./event gets notification.

After some digging I found out why. 


https://github.com/skarnet/s6/blob/master/src/libs6/ftrigw_notifyb_nosig.c#L33-L34

      if (strncmp(d->d_name, FTRIG1_PREFIX ":@", FTRIG1_PREFIXLEN + 2)) continue ;
      if (strlen(d->d_name) != FTRIG1_PREFIXLEN + 33) continue ;



I wonder what is the reason behind the naming convention? What is the
downside of simply writing to any present fifo file ?


Thanks 

Ihor

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ftrig pipe naming convention
  2022-09-18 15:41 ftrig pipe naming convention Ihor Antonov
@ 2022-09-18 20:38 ` Laurent Bercot
  2022-09-18 21:11   ` Ihor Antonov
  0 siblings, 1 reply; 3+ messages in thread
From: Laurent Bercot @ 2022-09-18 20:38 UTC (permalink / raw)
  To: supervision


>I wonder what is the reason behind the naming convention? What is the
>downside of simply writing to any present fifo file ?

  It could work like you're suggesting. But :

  - checking the type of a file is an additional fstat() system call
  - there may be reasons in the future to store other files in the
fifodir that do not receive the event
  - it is nice to detect stale fifos, if any, and delete them as soon
as you can (#L39), and you don't want to delete unrelated files
  - but most importantly: creating a fifo in a fifodir that allows you to
receive events without a race condition, which is the whole point of the
ftrig library, is slightly more complex to do safely than just "mkfifo
event/foobar", and I don't want people to think that this is the API.
No, the API is ftrigr_subscribe(), and everything under it is
implementation details. Restricting the naming is a way of ensuring
(as much as possible) that the fifos were indeed created by the
appropriate programs.

  Don't create fifos willy-nilly in a fifodir, and since you found the
naming convention, don't use it to work around the check to create your
fifos outside of ftrigr_subscribe(). If you do, it will work, until the
time when it doesn't, and it will be a complete PITA to debug.

--
  Laurent


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ftrig pipe naming convention
  2022-09-18 20:38 ` Laurent Bercot
@ 2022-09-18 21:11   ` Ihor Antonov
  0 siblings, 0 replies; 3+ messages in thread
From: Ihor Antonov @ 2022-09-18 21:11 UTC (permalink / raw)
  To: Laurent Bercot; +Cc: supervision

On 2022-09-18 20:38, Laurent Bercot wrote:
> 
> > I wonder what is the reason behind the naming convention? What is the
> > downside of simply writing to any present fifo file ?
> 
>  It could work like you're suggesting. But :
> 
>  - checking the type of a file is an additional fstat() system call
>  - there may be reasons in the future to store other files in the
> fifodir that do not receive the event
>  - it is nice to detect stale fifos, if any, and delete them as soon
> as you can (#L39), and you don't want to delete unrelated files
>  - but most importantly: creating a fifo in a fifodir that allows you to
> receive events without a race condition, which is the whole point of the
> ftrig library, is slightly more complex to do safely than just "mkfifo
> event/foobar", and I don't want people to think that this is the API.
> No, the API is ftrigr_subscribe(), and everything under it is
> implementation details. Restricting the naming is a way of ensuring
> (as much as possible) that the fifos were indeed created by the
> appropriate programs.

Could you please elaborate on the possible race condition? 
This is simply for curiosity and educational purposes. It feels like a
lot of thought was put into s6 codebase, and a lot of ideas are not
immediatedly obvious for people not intimately familiar with OS
interface.

> 
>  Don't create fifos willy-nilly in a fifodir, and since you found the
> naming convention, don't use it to work around the check to create your
> fifos outside of ftrigr_subscribe(). If you do, it will work, until the
> time when it doesn't, and it will be a complete PITA to debug.

This does make the most sense. We could say that pipes are also
implementation detail. There could be a socket, or, say, a regular file
(aka event log). So hiding this behind an interface is very reasonable.

> --
>  Laurent
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-09-18 21:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-18 15:41 ftrig pipe naming convention Ihor Antonov
2022-09-18 20:38 ` Laurent Bercot
2022-09-18 21:11   ` Ihor Antonov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).