In a

BuiltinGoal

, how do you retrieve the

OptionsBoostrapper

used?

no explicit way right now, afaict.

.new_session

doesn’t duplicate

SessionValues

into the new session

mm, yea.

should I add a method to

PySession

to allow access to the

SessionValues

?

that, or modify

new_session

to optionally keep them?

It doesn’t have access to them currently.

…but let’s maybe re-evaluate the assumptions around creating a new session. maybe the

bsp

goal should continue to use the original session.

SessionValues

is passed to the Rust side and not kept on the Python side.

@fast-nail-55400: or, maybe just switch back to using the original session.

could do that as well, but don’t we want to keep the whatever isolation is provided by making a new session?

we should always detect that the client doesn’t have a TTY, and thus never actually render the dynamic UI. even if we did though, it would be on stderr

how does inter-session locking work?

@fast-nail-55400: i think that it’s mostly about the UI… it’s already a dedicated session for the connection/run

ah got it. I’ll get rid of the

.new_session

for now.

@fast-nail-55400: there mostly isn’t any inter-session locking. multiple sessions interact with the

Graph

, which has internal locking. but the server itself has a lock for concurrent connections near the top of the stack (see): before shipping

bsp

that will need to be moved a bit probably (so that the

bsp

connection doesn’t hold that lock even when it is idling), since i don’t think we’ll resolve #7654 soon enough. but it’s not affected by session count.