Collaboration

[JPHutchins]

Hello! I was just about to open a new library and was checking asyncio naming conventions when I found aioserial.

I have not reviewed this repository extensively, but my initial impression is that it uses ThreadPoolExecutors to wrap the pySerial library.

My work with pySerial has focused on reworking its backend at the OS level to support asyncio with no need to create new threads. This, I believe, is a more elegant solution that fits with the OS API intended use and the "single thread spirit" of asyncio.

So far I have a working asyncio implementation using the Windows API. I am neither a Linux nor Windows developer, but more comfortable on Linux, and my gut feeling is that async serial will be supported by Linux APIs more easily than Windows.

Let me know if you would be interested in my contributing to this repository with the intention of replacing thread pools with native OS event signaling.

• J.P.

[mrjohannchang]

Hi @JPHutchins, yes of course! And it will be a huge improve! I should move this repo to an org then.

[JPHutchins]

@changyuheng Awesome! Work got a tad busy, but I've signed up for the python async and pywin32 mailing lists, each of which I need to submit some best practices questions to.

If you're curious, here is the quick modification of the Serial class to make it async: https://github.com/JPHutchins/pyserial/pull/1/files

It works, but the way that I listen for OS events:

        self._read_future = self._loop._proactor.wait_for_handle(self._overlapped_read.hEvent)
        self._write_future = self._loop._proactor.wait_for_handle(self._overlapped_write.hEvent)

seems questionable so I hope that the python async mailing list can fill me in on best practices.

We'd have to decide on how to bring these changes in... probably just subclassing Serial and adding the async stuff would be simplest.

I'll be in touch after I learn more.

Cheers, J.P.