Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Not to Write a Signal Handler

741mhz.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: How Not to Write a Signal Handler

#41

Post by teacup50 »

fafner wrote: post #35
teacup50 wrote: post #19

Earlier quoted context omitted.

Bah. This is complete nonsense. EVFILT_VNODE is not complicated to use for the cases for which it was actually designed — monitoring a file descriptor. For more general file system monitoring, a new kqueue filter type would be ideal, but adding that does not require breaking or deprecating kqueue API; the whole point of kqueue is to provide a generic extensible event mechanism. Adding a recursive path monitoring filt…

If you begin your comment with "Bah. This is complete nonsense." then you should at least address all of my points... Especially when you confirm one thing I've said in your first sentence. EVFILT_VNODE's design it too limited. It can watch directories (which after being opened are just a file descriptor). But it doesn't give you the information you need although they are available when the event is generated. The on…

Why do you keep ascribing EVFILT_VNODE's limitations to the the fact that the kqueue API is well designed and extensible? The inotify designers had 5 years to figure out the constraints and implications of file system notifications -- of course that gave them the opportunity to explore a different approach. Imagine that, instead of ignoring the hard problem of generic event APIs and NIH'ing a bad one-off hack, they'd adopted kqueue and extended it with an EVFILT_DIR? The whole industry would have benefited.

Instead, they did the standard Linux thing of hacking together an incoherent bolt-on API because to do otherwise would require careful consideration and thought.

Blaming the BSDs for not adopting Linux's hack is nonsense.

Re: How Not to Write a Signal Handler

#42

Post by teacup50 »

qznc wrote: post #38

Why does the signal handler have to interrupt a thread? Why doesn't the OS just create a new thread to run the signal handler in? This would avoid this whole reentrancy problem and make the concurrency explicit.

The OS has to pause a thread that triggers a signal; how can it proceed if doing so would just segfault again?

Re: How Not to Write a Signal Handler

#43

Post by fafner »

teacup50 wrote: post #41
fafner wrote: post #35

Earlier quoted context omitted.

If you begin your comment with "Bah. This is complete nonsense." then you should at least address all of my points... Especially when you confirm one thing I've said in your first sentence. EVFILT_VNODE's design it too limited. It can watch directories (which after being opened are just a file descriptor). But it doesn't give you the information you need although they are available when the event is generated. The on…

Why do you keep ascribing EVFILT_VNODE's limitations to the the fact that the kqueue API is well designed and extensible? The inotify designers had 5 years to figure out the constraints and implications of file system notifications -- of course that gave them the opportunity to explore a different approach. Imagine that, instead of ignoring the hard problem of generic event APIs and NIH'ing a bad one-off hack, they'd…

I have explained it several times now: The Linux devs had 5 years to come up with the inotify design because their API is more flexible. If you design things along the lines of "do one thing and do it well" instead of "let's cram everything into it" then you gain that flexibility. That's where the kqueue API fails and that's why it is not as good as the Linux approach. You talk about "extensible". But extensible really means touching the kqueue API because that's the only way to extend it. On Linux epoll is far more extensible because it just means adding a new descriptor type.

I don't know why you claim that Linux ignored the hard problem of generic event APIs. Unlike kqueue, Linux has a truly generic event API. That's what I've explaining since the beginning.

Even if Linux had added kqueue and added an EVFILT_DIR then there would have been no guarantee that the BSD's would adopt the same API. There is no committee in charge of kqueue. The licenses are not portable and even if they'd agree on being compatible for kqueue then this would touch parts beyond it. And then there is the huge questions, why a directory and a file should be treated differently, when the only difference is the provided meta data.

Apple apparently has added a completely different approach to fs notifications. Based on a device and a deamon. Why didn't they just add an EVFILT_DIR, if that's as easy as you claim? Why didn't the BSDs do it?

Claiming that inotify is a hack or incoherent is just beyond ridiculous. Inotify is far better than anything kqueue offers. So if anything then kqueue is a hack and badly thought out...

If the BSD folks would simply adopt inotify then it would be one less painful thing to deal with when porting applications to BSD. All I hear nowadays is BSD folks complaining that the Linux folks are doing things differently and BSD has a hard time getting all the software to run they want. So adopting inotify would make it easier for the BSDs. In the end I don't care. But at least they should come up with a somewhat decent API. Doesn't matter if it's inotify or some NIH'ing.

Re: How Not to Write a Signal Handler

#44

Post by fafner »

kev009 wrote: post #18
fafner wrote: post #7

Earlier quoted context omitted.

I think the kqueue interface is a lot worse than the Linux way. With kqueue everything is forced through one interface. In Linux it's just file descriptors and epoll to deal with them. It is a nice extension of the "everything is a file" mechanism and it embodies the "do one thing and do it right". This becomes apparent when you look at fs notifications. You've already mentioned how inotify is superior to kqueue. I m…

There's been talk (at BSDCam) of implementing inotify which is needed for the Linuxulator and exposing it in the FreeBSD API too. So your wish isn't so far fetched but I'm not sure anyone is actively working on it. Patches welcome :)

That would be a good decision. So far I've only seen an attempt to implement inotify on top of kqueue. Which of course will be buggy and incomplete.

Re: How Not to Write a Signal Handler

#45

Post by fulafel »

teacup50 wrote: post #42
qznc wrote: post #38

Why does the signal handler have to interrupt a thread? Why doesn't the OS just create a new thread to run the signal handler in? This would avoid this whole reentrancy problem and make the concurrency explicit.

The OS has to pause a thread that triggers a signal; how can it proceed if doing so would just segfault again?

Only a subset of signals come from mapping CPU faults to signals, the so-called synchronous signals. This example was about SIGINT coming from the usual source (Ctrl-C from terminal).

It's actually possible to handle it in a thread using existing semantics without kqueue or signalfd: block SIGINT from all threads except your dedicated SIGINT-handling thread.

Re: How Not to Write a Signal Handler

#46

Post by teacup50 »

fafner wrote: post #43
teacup50 wrote: post #41

Earlier quoted context omitted.

Why do you keep ascribing EVFILT_VNODE's limitations to the the fact that the kqueue API is well designed and extensible? The inotify designers had 5 years to figure out the constraints and implications of file system notifications -- of course that gave them the opportunity to explore a different approach. Imagine that, instead of ignoring the hard problem of generic event APIs and NIH'ing a bad one-off hack, they'd…

I have explained it several times now: The Linux devs had 5 years to come up with the inotify design because their API is more flexible. If you design things along the lines of "do one thing and do it well" instead of "let's cram everything into it" then you gain that flexibility. That's where the kqueue API fails and that's why it is not as good as the Linux approach. You talk about "extensible". But extensible real…

You're absolutely 100% full of crap. I already explained how kqueue's flexibility means that an EVFILT_DIR can be added easily, and work with all other event mechanisms on the system.

> The Linux devs had 5 years to come up with the inotify design because their API is more flexible.

That doesn't even begin to make sense. There's nothing inherent in the kqueue API that mandates that all filter types be defined upfront and never be extended or modified.

> On Linux epoll is far more extensible because it just means adding a new descriptor type.

How is that more extensible? The whole point of kqueue is that there exists a class of event types for which a read-based FD API is not the most efficient mechanism for event dispatch.

> Apple apparently has added a completely different approach to fs notifications. Based on a device and a deamon. Why didn't they just add an EVFILT_DIR, if that's as easy as you claim?

Corporate developer politics. The people working on kqueue and the people working on Spotlight (the primary FSEvent consumer) were in two separate universes.

> Why didn't the BSDs do it?

It clearly hasn't been a priority for anyone; kqueue meets most needs just fine.

Re: How Not to Write a Signal Handler

#47

Post by teacup50 »

fulafel wrote: post #45
teacup50 wrote: post #42

Earlier quoted context omitted.

The OS has to pause a thread that triggers a signal; how can it proceed if doing so would just segfault again?

Only a subset of signals come from mapping CPU faults to signals, the so-called synchronous signals. This example was about SIGINT coming from the usual source (Ctrl-C from terminal). It's actually possible to handle it in a thread using existing semantics without kqueue or signalfd: block SIGINT from all threads except your dedicated SIGINT-handling thread.

That requires that you have control over all threads, which is just not something that can be guaranteed with modern operating systems and libraries that regularly spawn their own threads.

Thread-interrupting delivery of signals is necessary in a world where you're relying on that interruption of your single thread; a replacement that worked for the async signals is useful, but distinct from the needs of sync signal handling.

Re: How Not to Write a Signal Handler

#48

Post by kelnos »

fulafel wrote: post #45
teacup50 wrote: post #42

Earlier quoted context omitted.

The OS has to pause a thread that triggers a signal; how can it proceed if doing so would just segfault again?

Only a subset of signals come from mapping CPU faults to signals, the so-called synchronous signals. This example was about SIGINT coming from the usual source (Ctrl-C from terminal). It's actually possible to handle it in a thread using existing semantics without kqueue or signalfd: block SIGINT from all threads except your dedicated SIGINT-handling thread.

That doesn't actually work 100%: signals can be sent to the process as a whole or to a specific thread. The SIGINT-handling thread will be able to handle signals sent to the process, but not to any other thread of the program.

Re: How Not to Write a Signal Handler

#49

Post by fafner »

teacup50 wrote: post #46
fafner wrote: post #43

Earlier quoted context omitted.

I have explained it several times now: The Linux devs had 5 years to come up with the inotify design because their API is more flexible. If you design things along the lines of "do one thing and do it well" instead of "let's cram everything into it" then you gain that flexibility. That's where the kqueue API fails and that's why it is not as good as the Linux approach. You talk about "extensible". But extensible real…

You're absolutely 100% full of crap. I already explained how kqueue's flexibility means that an EVFILT_DIR can be added easily, and work with all other event mechanisms on the system. > The Linux devs had 5 years to come up with the inotify design because their API is more flexible. That doesn't even begin to make sense. There's nothing inherent in the kqueue API that mandates that all filter types be defined upfront…

You are not helping your point by insulting me. I know that EVFILT_DIR can be added. I never disputed that. But it needs changes to the kqueue API. And apparently it is not so easy because nobody has done it and even operating systems using kqueue have opted to do it differently. You can talk all day about how things could be done theoretically. But that doesn't matter if reality looks so much different. Maybe you should ask yourself why EVFILT_VNODE was so poorly designed.

Re: How Not to Write a Signal Handler

#50

Post by teacup50 »

fafner wrote: post #49
teacup50 wrote: post #46

Earlier quoted context omitted.

You're absolutely 100% full of crap. I already explained how kqueue's flexibility means that an EVFILT_DIR can be added easily, and work with all other event mechanisms on the system. > The Linux devs had 5 years to come up with the inotify design because their API is more flexible. That doesn't even begin to make sense. There's nothing inherent in the kqueue API that mandates that all filter types be defined upfront…

You are not helping your point by insulting me. I know that EVFILT_DIR can be added. I never disputed that. But it needs changes to the kqueue API. And apparently it is not so easy because nobody has done it and even operating systems using kqueue have opted to do it differently. You can talk all day about how things could be done theoretically. But that doesn't matter if reality looks so much different. Maybe you sh…

If by "changes to the kqueue" API you mean "adding a new filter type, as kqueue was designed to support", then how is the kqueue API poorly designed? Why should the BSDs adopt a completely separate inotify hack?

"100% full of crap" is an accurate assessment when you keep trotting out completely nonsense arguments as fact instead of actually engaging on the technical content; consider it my adopting of Linus' discussion style. Is there some specific problem that can't be solved within the confines of the existing kevent types and data structures?

This seems pretty simple:

- EVFILT_VNODE isn't poorly designed for the use-case of monitoring a file.

- EVFILT_VNODE is poorly designed for the use-case of monitoring a directory hierarchy, but that isn't the intended use case.

Nowhere have you demonstrated why the BSDs should drop kqueue in favor of Linux's hack; as for why it hasn't been implemented: because apparently no other kernel developers have needed it badly enough.

Mac OS X FSEvents as a counter-example doesn't hold technical water; the reasons for FSEvents being separate from kqueue are solely to do with Apple's internal political machinations, and you've provided no technical analysis that demonstrate otherwise.

Post reply on HN