You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 standardbreakpoint()
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 syncbreakpoint()
(obviously by overriding the default hook). We can also try just scheduling the parent tty locking sequence usingActor._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 normaltractor.breakpoint()
, blocking until the tty lock is release, it might just work?Needs some experimentation for sure.
The text was updated successfully, but these errors were encountered: