reintroduce signal handling

[jhellerstein]

We used to have a buggy signal handling solution, which was removed in commit 032bf1d. It would be good to have a similar but working solution that addresses the problems discussed in that commit.

[neilconway]

Sure, happy to chat about a sane way to provide support for it. Roughly speaking, I think it should be safe to:

1. set global variables in the signal handler
2. periodically poll those variables in the signal check thread
3. have that thread enqueue events to be consumed by the active Bud instances, which could then turn them into tuples; similarly to how inbound network events are handled

[jhellerstein]

Yes, making it work isomorphically to network events (and periodics) would be best.

J

On Jan 21, 2013, at 3:31 PM, Neil Conway notifications@github.com wrote:

Sure, happy to chat about a sane way to provide support for it. Roughly speaking, I think it should be safe to:

set global variables in the signal handler
periodically poll those variables in the signal check thread
have that thread enqueue events to be consumed by the active Bud instances, which could then turn them into tuples; similarly to how inbound network events are handled
—
Reply to this email directly or view it on GitHub.