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 >