You can inject any transport as long as it’s based on a stream of characters
so drawbridge is out (what’s the point of injecting a HTTP transport over an SSH tunneled socket repl)
binary transports are out too (ok maybe with a good amount of reflection it may be worked out)
Is *msg*
dead code or something used for debug?
@cgrand I think without it being bound responses don’t have ids.
What lead you to believe it might be dead code?
I didn’t look into session for it 😕 (I really thought I did search the whole codebase)
now I feel less bad about creating a circular dep between session and interruptible-eval
So thread management should move to session (where clone
and close
are handled)
As *msg*
is just an implementation detail perhaps you can also find a different way to track the active message.
I don’t think that any user code depends on this.
But moving thread management to sessions is also reasonable. The only tricky part will be retaining the thread-local bindings between threads.
@bozhidar Bindings of dynvars or of ThreadLocals? I don’t know if you’ve read my latest proposal on #16: a thread per session with a caveat emptor about interrupting evaluation.
Btw in addition to interrupt in unrepl we have the ability to background the current eval (it returns immediately as a future).
> a thread per session with a caveat emptor about interrupting evaluation.
Yeah, that makes a lot of sense. And solves the problem I was thinking about - namely preserving the dynvar bindings, as those are stored in the session anyways.
> Btw in addition to interrupt in unrepl we have the ability to background the current eval (it returns immediately as a future).
I guess that something like this might be useful to some people who want to enqueue a few long-running evaluations, but I’m not certain how common this scenario is.