Charles-François Natali added the comment: > I would like to suggest again my idea of doing it in Connection instead, > with new methods (e.g. locked_send and locked_recv). Especially given > it can be useful in user code to have a thread-safe Connection (I'm in > this situation currently).
I intended to do this initially, but then it turned out to be much more intrusive than what I initially thought, and opted for a simpler approach. While it's probably a good idea to implement it in Connection, I don't really like the idea of adding new distinct methods: - this would require allocating locks for every connection, which wouldn't be used most of the time - since locks are implemented atop POSIX semaphores and some platforms only support a handful of them, it could trigger some failure - it's not really just adding locked_send() and locked_recv(): you must implemented locked send_bytes/send/recv_bytes/recv_bytes_into/recv: also, if we want to implement timed and non blocking receive (which is supported by Queue.get), it should probably be handled here So basically, I think the right way to do it would be to define an abstract ConcurrentConnection, or AtomicConnection which would override Connection methods making them thread/process safe. We'd also need exposing AtomicPipe... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17025> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
