By default switchio's internal event loop spawns a background thread which runs an asyncio event loop for processing events from FS. The original reason for this was legacy (before porting to asyncio) but still serves a useful purpose - that you can run switchio non-blocking alongside other blocking frameworks or programs from a single python process.
Now that this project is officially python 3.5+ only and has full support for asyncio we should allow users to be able to run event processing all in thread (using one asyncio loop) if desired.
The changes required for this shouldn't be too hard, but we'll need to mess with some plumbing:
By default
switchio
's internal event loop spawns a background thread which runs anasyncio
event loop for processing events from FS. The original reason for this was legacy (before porting toasyncio
) but still serves a useful purpose - that you can runswitchio
non-blocking alongside other blocking frameworks or programs from a single python process.Now that this project is officially python 3.5+ only and has full support for
asyncio
we should allow users to be able to run event processing all in thread (using oneasyncio
loop) if desired.The changes required for this shouldn't be too hard, but we'll need to mess with some plumbing:
asyncio
loop (that can be run from the top most level) all the way down to core machineryClient
needs to support aloop
arg to allow passing it down to the contained listener and any other connectionsEventListener
kind of already supports it since you can pass in anasyncio
loop when creating a newEventLoop
(see below)EventLoop
already supports thisSee @enp's example app using just the
switchio.api.Connection
in #61 for the original use case.