On 29/09/2015 00:08, Buck Evan wrote:
If it's not good for s6, I'm not sure it's good for my framework either.
Not necessarily. s6-supervise is extremely paranoid; depending on its use cases, your framework doesn't have to be. Also, if you control both ends of a named pipe and can reasonably assume that nobody's going to mess with them, that's a lot safer than having a named pipe as part of a public interface.
Would this be a good candidate for the ftrig* stuff? It does seem like event notification.
fifodirs internally use named pipes ;) That would probably make your interface more complex than it needs to be.
Or: How do you pass a file descriptor such that it can be used by a parent process?
By fd-passing, which is black magic over a Unix domain socket. You need your client (child of ./run) and your server (your framework) to communicate over a Unix socket (have the server listen and accept to some socket in the filesystem, have your client connect to it), and there are functions to magically copy a descriptor from one to the other. Google "fd-passing". I have functions in skalibs to make it easier to transfer fds along with text over a stream socket: unixmessage.h See s6-sudoc.c and s6-sudod.c for a relatively simple usage example.
I'd need to document "you need to write a ./ready script *and* prefix your service with my-poll-helper". If I can get this down to just one thing that people have to do right, it's going to work better.
'Your run script must be called "./run.framework" no matter what' 'If you want poll support, write a ./ready script' Then automate the creation of ./run files that will just exec "my-poll-helper ./run.framework". And my-poll-helper tests for ./ready scripts and does what it needs, just executing into its argument if there's no valid ./ready script. You don't even need to connect my-poll-helper to the framework in that case: you can just have it do its ./ready polling in the background and write a newline to notification-fd when it succeeds, as we talked about earlier. Wrapping ./run gives you a lot of freedom.
An svc --hey-im-ready option would continue that trend.
Using s6-supervise's control pipe as the mechanism to report readiness. Yes, that's a possibility, and I thought about it, but ultimately rejected it, because s6-svc sends orders to control the service, not to fake its state. s6-supervise tries to always report the *real* state, not an arbitrary state defined by the user. You have to realize that all this discussion is about an attempt to make s6-supervise report a fake state when the daemon doesn't have support: no wonder it's difficult! I didn't make it intentionally difficult, but I didn't design the thing around making it easy to fake states, either. A s6-svc option to fake a state would make it a bit *too* easy for my taste. Wrap the goddamn run script. It's by far the easiest way to get what you want. -- Laurent
