Evaluate code in a separate thread

[danielwaterworth]

Since you can't lock mutexes in a signal handler, using the repl is otherwise a significantly less pleasant experience.

[SamSaffron]

Is this cheating? does this have a chance of blocking the signal handler for many seconds? I worry that we open up the door to having a process not react to signals at all while this is happening.

perhaps cli should just queue the work and have a thread that runs to watch state? signal handler just injects the work, then you poll for state? something like that?

[danielwaterworth]

does this have a chance of blocking the signal handler for many seconds?

There's no change in that respect - we were evaluating the snippets in a signal handler before.

I support replying to the user in a separate thread, but I think this is an improvement as is.

[SamSaffron]

OK... going to merge this as it is no worse than what we have today, but I would love to figure out a way of keeping the process signal handler unblocked

[casperisfine]

Hum, this break our usage of rbtrace. For context we use it (among other things) to get the current stacktrace of a running process before killing unicorn workers that timed out:

t = RBTracer.new(pid)
if res = t.eval("caller.join('|')")
  res[1..-2].split('|')
end

[casperisfine]

I suppose I can do like the --backtraces option, however that one should be updated to ignore that new background thread.

        code = "Thread.list.map{|t| t.backtrace[0...#{num}].join(\"#{delim}\")}.join(\"#{delim*2}\")"