Honestly, I don't know your use case. Good luck though!
On Wednesday, September 24, 2014, Arve Knudsen
wrote:
> I think you make a good point. My solution in the meantime has been to
> check a multiprocessing.Qeue periodically instead (via the event loop's
> call_later method), since the scenari
I think you make a good point. My solution in the meantime has been to
check a multiprocessing.Qeue periodically instead (via the event loop's
call_later method), since the scenario is to act on messages from a child
process. I think it works quite well, and I could do away with the thread I
was or
Maybe the following can be made to work? Use two threads, each with an
event loop. One thread uses a SelectorEventLoop, the other uses a
ProactorEventLoop. Callbacks and coroutines running in these threads
threads should communicate using call_soon_threadsafe(). (I suppose very
brief periods of loc
Hi. I'm author of aiozmq.
The library has very limited Windows support (Windows is a
second-class citizen in 0MQ world btw).
It cannot work with ProactorEventLoop and there is no way to solve the
issue due 0MQ API limitations.
Old-style ZmqEventLoop (with ZmqEventLoopPolicy) can be used as
replac
I don't know much about the Windows primitives used by Proactor -- the best
I can recommend is that you try to figure out how to do this by studying
the source and experimenting, and then suggest a patch.
On Tue, Sep 23, 2014 at 11:51 PM, Arve Knudsen
wrote:
> Hi guys
>
> Is there some way to wo
Hi guys
Is there some way to work around the missing support for
add_reader/add_writer in asyncio.ProactorEventLoop? Specifically, I'm
trying to use a library (aiozmq) that detects when it's able to read from
sockets (via add_reader) and to write to sockets (via add_writer), and I
would like to co
