<tinnvec>
I've used a "SIGINT" trap in the past to catch Ctrl-C and try to quit out more gracefully, I've recently been seeing an issue with "`synchronize': can't be called from trap context"
<dominikh>
yeah. it doesn't work with Ruby 2.x anymore. I haven't yet thought about a new solution
<tinnvec>
ah gotcha haha I was just typing that I had jumped to ruby 2 recently
<dominikh>
you will need to find a way to set some state that can be monitored outside of the trap handler
<dominikh>
a variable and busy looping is the obvious (and horrible) choice. I don't know if there's anything less horrible that works and isn't considered too "expensive" to be called inside a trap handler by ruby
<tinnvec>
I see what you mean, that doesn't sound great lol
<tinnvec>
I only noticed because I was testing things and actually looking at the output
<tinnvec>
so i think all-in-all it's not a show stopping deal
<leftylink>
oh yeah I forgot what weird conclusion I came to last time...
<leftylink>
that you can't synchronize on a mutex, but you can signal on a condition var
<leftylink>
which, well, does that seem inconsistent at all? well just a little bit, but maybe there's something I don't know
<leftylink>
like, http://sprunge.us/KOCh works. I'm not sure what the proper saying is for this in english, something like "there is no justice in the world" or something
<leftylink>
something to express that it makes no sense that I can't synchronize on a muted but I can signal a different thread that will synchronize on a mutex
<dominikh>
actually that makes perfect sense
<leftylink>
oh, help me out then
<leftylink>
let me look at my notes from last time...
<dominikh>
a signal handler should return as quickly as possible. it telling the runtime "schedule that other thread" doesn't mean the handler cannot return until that thread did its job
<dominikh>
the handler sets a bit and is done
<dominikh>
if the handler itself acquired a mutex, it could block indefinitely if the mutex is locked and never unlocked
<dominikh>
so yeah, they're really quite different beasts
<leftylink>
okay, this is sensible enough to me. I think the part that was missing in my understanding was the realization that the handler just signals and returns, no problems there
<leftylink>
all right
<dominikh>
also tinnvec ^^ is how to solve this
<leftylink>
I guess they want to prevent a class of unsafe behaviors in saying "no you cant acquire a mutex". and last time this got brought up I was lamenting the fact that there's no way they can possibly prevent all unsafe behaviors (for example, loop {}, or maybe calling Thread#join on a blocked thread), but I suppose preventing one class of unsafe behaviors is strictly better than the world they were in before
<leftylink>
unless it lulls people into a false sense of security of "they didn't tell me it's not OK therefore it's OK"... well, people shouldn't think that way =D
<dominikh>
I think there's some technical reason you can't lock a mutex, not an ideological reason. but I couldn't be arsed to actually read up on it
<tinnvec>
ah cool thanks guys, that actually helps explain a lot