search

bloom-lang / bud

Prototype Bud runtime (Bloom Under Development)
http://bloom-lang.net
Other
854 stars 60 forks source link

reintroduce signal handling #287

Open jhellerstein opened 11 years ago

jhellerstein commented 11 years ago

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

neilconway commented 11 years ago

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 commented 11 years ago

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.