Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling breakpoint() usage from sync code #167

Open
goodboy opened this issue Nov 17, 2020 · 1 comment
Open

Handling breakpoint() usage from sync code #167

goodboy opened this issue Nov 17, 2020 · 1 comment
Labels
debugger experiment Exploratory design and testing help wanted Extra attention is needed

Comments

@goodboy
Copy link
Owner

goodboy commented Nov 17, 2020

With the introduction of our multi-process debugger system in #126 via await tractor.breakpoint(), we probably need to consider how a user can call the standard breakpoint() from sync code in multiple (sub)actors.

There shouldn't be a conflict as long as multiple agents don't request the tty lock simultaneously at which point the sync breakpoint() may clobber some other actor's tty i/o.

An initial off-the-cuff idea is to just use trio.from_thread.run() from a new thread that is spawned at the point of a sync breakpoint() (obviously by overriding the default hook). We can also try just scheduling the parent tty locking sequence using Actor._service_n.start_soon() like we do normally in the root actor and it may work just fine?

The main conceivable issue with the latter will be of course that locking / queuing for the tty lock won't work with just the sync code but if we were to first launch a thread with trio.to_thread.run() which then calls the normal tractor.breakpoint(), blocking until the tty lock is release, it might just work?

Needs some experimentation for sure.

@goodboy goodboy added help wanted Extra attention is needed experiment Exploratory design and testing debugging labels Nov 17, 2020
@goodboy
Copy link
Owner Author

goodboy commented Feb 22, 2021

Partially solved by #194 (in terms of avoiding issues with cancellation once inside pdb).

Relates heavily to #193.

@goodboy goodboy added debugger and removed debugging labels Aug 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debugger experiment Exploratory design and testing help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant