Do you remember how well threads worked compared to greenlets?

I think it was about twice the latency, but I should measure.
On Tue, Oct 11, 2016 at 5:09 PM Sebastian Ramacher notifications@github.com
wrote:

Do you remember how well threads worked compared to greenlets?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#641 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcAf-rl7WOyiz8X029nYdTQg3C7qPGwks5qy_slgaJpZM4KSxIH
.

If someone wants to look at this, the process be doing about the opposite of commit 2e54cbb to move us back to threads, then playing around to see how it feels.

I started #681 to work on this. I need some dedicated time with a whiteboard to really dive in and understand the threading model, but this looks promising so far.

(I've obviously made no progress on this, other implementations welcome!)

I think using threads the same way greenlets are currently used would not fix the issue: user sets up a "threadlocal" in their shell or embedding environment, submits a statement to bpython, bpython decides to perform the evaluation in an other thread / greenlet (I'm guessing? or the failure makes no sense).

If the statement accessed the threadlocal, the evaluation might blow up because it's not been setup in the other threads / greenlets of bpython's pool (or maybe it never works at all if bpython spawns a new greenlet for each evaluation).