Hi Andrey, On Sun, Jan 20, 2013 at 6:41 PM, Andrew Vagin <avagin@xxxxxxxxxxxxx> wrote: > >> > signalfd is a special descriptor, so I think it >> > is not a big deal, that it works a bit strange. >> >> Sure, but the more we special case things, the uglier the ABI as a >> whole becomes. So special casing should be avoided as far as we can. >> >> > If all other would >> > decides, that a new syscall is better, I will not ague. >> >> And that's more or less how I see it too. I'm not going to argue for a >> new syscall, based on what I know so far. >> >> Here is one idea to think about though, while more or less maintaining >> your proposed interface. >> >> At the moment, you select signal queues in the pread() call. An >> alternative would be to do it in the signalfd() call. In other words, >> you could have the following flags used with signalfd() >> >> SFD_RAW >> SFD_SHARED_QUEUE -- reads will be from process-wide shared signal queue >> SFD_PER_THREAD_QUEUE --reads will be from per-thread signal queue > > I suggested this variant in the initial series, but then we decided to > avoid adding new flags. Oleg, what do you think about this? > >> >> Specifying both SFD_SHARED_QUEUE and SFD_PER_THREAD_QUEUE would be >> the same as omitting them both, providing the default behavior of >> slecting from both queues. >> >> My point here is that you can then separate the RAW functionality from >> the queue selector functionality. Now, it might be that at the moment >> you always require that if the caller specifies SFD_SHARED_QUEUE or >> SFD_PER_THREAD_QUEUE, then they must also specify SFD_RAW. But later, >> that constraint might be relaxed, so that users could use signalfd() >> to select from a particular queue when reading traditional (non-RAW) >> signalfd_siginfo structures from a signalfd. > > I am not sure, that you understood this moment correctly. > Currently SFD_RAW is independent on SFD_*_QUEUE. If signalfd is > created without SFD_RAW, pread returns signalfd_siginfo-s. > If SFD_RAW is set, read returns siginfo_t-s. So, do you mean it is already possible to do: fd = signalfd(-1, &mask, 0) // no SFD_RAW flag pread(fd, buf, count, SFD_PER_THREAD_QUEUE_OFFSET + pos) to read a siginfo from the thread specific signal queue? Thanks > One more point for two flags is that we will be able to choose a queue > from which signals will be dequeued. Currently we can choose a queue only > for pread. Also a good point, and another reason to place queue selection in the signalfd() call, rather than in pread(). Cheers, Michael >> This does seem like a >> very sensible design optimization to make now (and an easy one, I >> would suppose). What do you think? >> >> Cheers, >> >> Michael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-api" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
