Under ubuntu python-gevent kills packets #396

Closed
opened 2013-08-11 04:46:22 +02:00 by VikOlliver · 2 comments
VikOlliver commented 2013-08-11 04:46:22 +02:00 (Migrated from github.com)

I'm running Ubuntu precise. I saw a message scroll past in the console suggesting that gevents could not be found but that it didn't matter. I installed python-gevent and could no longer establish sockets. Removing python-gevent fixed the problem so I've left it at that.

Vik :v)

I'm running Ubuntu precise. I saw a message scroll past in the console suggesting that gevents could not be found but that it didn't matter. I installed python-gevent and could no longer establish sockets. Removing python-gevent fixed the problem so I've left it at that. Vik :v)
fiatflux commented 2013-08-11 12:10:46 +02:00 (Migrated from github.com)

This is very interesting. In a separate issue (#312) we're having trouble with gevent and multiprocess PoW. The underlying cause being that the multiprocessing module's transport layer expects socket to block but gevent patches the socket module to be non-blocking. But this is the first time I have heard of gevent causing problems for other bitmessage sockets... very weird. It's worth hunting around for places where child processes might cause funny libev states as is found in proof_of_work._doFastPow, but on cursory inspection I can't find anything that would do this elsewhere.

This is my first time working with gevent... can someone explain to me how it's helping pybitmessage in any way other than async IO? It's certainly convenient but the manner in which it achieves convenience seems really problematic from a reliability/maintainability standpoint. Maybe we should consider looking into other AIO options like ZeroMQ. Thoughts, anyone?

This is very interesting. In a separate issue (#312) we're having trouble with gevent and multiprocess PoW. The underlying cause being that the multiprocessing module's transport layer expects socket to block but gevent patches the socket module to be non-blocking. But this is the first time I have heard of gevent causing problems for other bitmessage sockets... very weird. It's worth hunting around for places where child processes might cause funny libev states as is found in proof_of_work._doFastPow, but on cursory inspection I can't find anything that would do this elsewhere. This is my first time working with gevent... can someone explain to me how it's helping pybitmessage in any way other than async IO? It's certainly convenient but the manner in which it achieves convenience seems really problematic from a reliability/maintainability standpoint. Maybe we should consider looking into other AIO options like ZeroMQ. Thoughts, anyone?
grant-olson commented 2013-08-26 19:01:14 +02:00 (Migrated from github.com)

This code is gone now right? Should be able to close the issue.

This code is gone now right? Should be able to close the issue.
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-04#396
No description provided.