Thread safety

[nixme]

No description provided.

[jrochkind]

any hints as to what it would take to make this happen? I'd really like to see it.

[nixme]

@jrochkind Have you tried using pry-nav with threads? Looking through the source, I'm trying to remember why I thought it wasn't thread-safe. Of course, you can only call binding.pry from one thread, but otherwise everything looks fine. Give it a shot and let me know if you run into issues.

[jrochkind]

Awesome, thanks. I have not yet, but with this encouragement will try
to find time to try.

pry with pry_nav looks like it comes close to being a ruby_debug
debugger replacement -- but the only way to trigger dropping to
interactive session is with binding.pry in source, there's no way to
set a breakpoint by file and line number like there is with
ruby_debug... or is there?

(With ruby_debug, I find that useful most especially when I want to
set a breakpoint inside the source of some third party gem, often
using the file/line number from a stack trace from an exception raised
by that gem).

On Thu, Feb 16, 2012 at 1:01 PM, Gopal Patel
[email protected]
wrote:

@jrochkind Have you tried using pry-nav with threads? Looking through the source, I'm trying to remember why I thought it wasn't thread-safe. Of course, you can only call binding.pry from one thread, but otherwise everything looks fine. Give it a shot and let me know if you run into issues.

---

Reply to this email directly or view it on GitHub:
#2 (comment)

[nixme]

@jrochkind If you're looking for something closer to ruby-debug, check out pry_debug.

One goal I had for pry-nav was that the command to execute a program shouldn't change. So no binary/script to wrap a program. This is so you can start debugging a rails app or anything that autoreloads classes without restarting the process.

However, there's definitely some features of pry_debug that I might be able to pull into pry-nav. Perhaps setting a breakpoint with a breakpoint command and then running continue. Although for that type of usage I recommend ruby-debug since the tracing functionality used by both pry-nav and pry_debug is quite slow.

[nixme]

Actually, I realize that the tracer isn't thread-safe and will incorrectly count frames if there's a background thread running. The fix should be relatively easy: all instance variables in PryNav::Tracer need to be thread local.

[jrochkind]

I might find time to create a pull request for that "all instance variables in PryNav::Tracer ned to be thread local" -- any other hints or guidance for me or anyone else who comes along and sees this?

On the general debugger issue; ruby-debug has been converted to 'debugger' and now sometimes sort of kind of works on ruby 1.9.3, but i still have problems with it, and am enticed by pry's great UI and featureset.

But I need threadsafety. I also need ability to set a breakpoint at the pry prompt. I agree with you that I don't want to have to change the command to execute the program, no binary/script wrapper. ruby-debug/debugger actually lets you run without a binary/script wrapper, and still set breakpoints at the debugger console, and then continue. This is super useful. It's not clear to me if pry-debug will let me do that, i think pry-debug does require a binary/script wrapper, changed command to execute?

[jrochkind]

huh, actually pry_debug lets you call invoking program as normal but then PryDebug.start_pry binding according to docs. I haven't tried it yet. pry_debug also claims to be thread-safe.

PryDebug will ensure that only one thread uses Pry. It will also keep information about breakpoints and stepping on a thread basis, to avoid unexpected and undetermined results.

The feature set of these two pry plugins is very similar. However, yours is definitely the more popular one, with more recent commits and more faith that it'll be maintained. :) It would be ideal if they could be merged somehow, or at least if you want to borrow the most useful features from pry-debug.

[nixme]

@jrochkind Not sure if pry_debug worked out for you, but check out pry-debugger, a rewrite of pry-nav using debugger as the tracer. Also includes breakpoint support.

[jrochkind]

Thanks @nixme, i'll try to find time to give it a try.

ruby-debug is increasingly sketchy, i think there are others interested in a replacement -- meaning thread-safe, and with ability to set breakpoints.

[jrochkind]

@nixme, Oh, wait, I see pry-debugger actually uses debugger (nee ruby-debug19). Sadly, the reason I'm interested in pry is because debugger just doesn't work that well for me anymore (like only showing the first line of a backtrace for some reason. issue 16), and seems to generally not have sufficient developer support to keep it working reliably these days.

[nixme]

You might still want to give pry-debugger a shot as it only uses debugger for tracing. Everything else (e.g. whereami) comes from pry. You can get backtraces by adding pry-stack_explorer although there's a small bug where they don't work on step, but that'll get fixed in the next few days.

Thread safety will come soon as debugger's threading support is still better than set_trace_proc.

[jrochkind]

Awesome, i'll try to keep my eye on it, and plan to dive in when multi-
threading support is there.

I have to admit I'm a bit put off by all the parts I need to combine
to get the pry pieces to be a debugger. Perhaps once the various parts
are a bit more mature, someone can put together a gem which merely
aggregates the various pry pieces needed to be a one-gem install:
Install This To Get a Debugger Via Pry. Instead of having to hunt
around and figure out which gems one needs to combine and install/
require how. It's probably invisible to you as a developer intimately
familiar with it all, but I suspect I'm not the only one in my case: A
debugger is a tool, I need to get it working for me without a lot of
trouble, having to hunt around for all the various pieces (with
alternative options) to combine to do what I want with pry is a non-
trivial time barrier compared to: Just add the ruby-debug/debugger
gem, and go (If only it worked reliably. And of course, pry is nicer
UI anyways too, once you get it going).

On Jun 18, 2012, at 10:03 PM, Gopal Patel wrote:

You might still want to give pry-debugger a shot as it only uses
debugger for tracing. Everything else (e.g. whereami) comes from
pry. You can get backtraces by adding pry-stack_explorer although
there's a [small bug](https://github.com/nixme/pry-debugger/issues/
8) where they don't work on step, but that'll get fixed in the next
few days.

Thread safety will come soon as debugger's threading support is
still better than set_trace_proc.

---

Reply to this email directly or view it on GitHub:
#2 (comment)

[nixme]

I think that's because pry wasn't originally conceived of as a debugger but rather a IRB replacement.

But I agree, and that's why I created the jazz_hands gem: https://github.com/nixme/jazz_hands. However it's tailored specifically for Rails apps.