Changes between Initial Version and Version 1 of Ticket #23251, comment 2


Ignore:
Timestamp:
Aug 15, 2017, 8:31:12 PM (21 months ago)
Author:
isis
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #23251, comment 2

    initial v1  
    99> As for Stem not being 'async aware' I'm not sure what you mean or why that's relevant. You're just using Stem as a descriptor parser. That has nothing to do with its controller functionality.
    1010 
    11 Oh, I mean that BridgeDB is Twisted python, so it's main loop is asynchronous. But while BridgeDB is doing it's `bridgedb.parse.descriptors.*` functions (which call Stem) the handling of the file isn't done in the way that Twisted is happy with because it's blocking (see the `FileWriter(proto.Protocol)` class in the `bridgedb.git/scripts/get-tor-exits` script for an exmaple of how Twisted wants IO to be done). So because this IO is all blocking, and because of the hang bug, it never returns to BridgeDB's main loop, which is where the handlers for the SIGUSR1 and SIGHUPs signals are, which are required to restart BridgeDB when it receives new descriptors from the BridgeAuth.
     11Oh, I mean that BridgeDB is Twisted python, so its main loop is asynchronous. But while BridgeDB is doing it's `bridgedb.parse.descriptors.*` functions (which call Stem) the handling of the file isn't done in the way that Twisted is happy with because it's blocking (see the `FileWriter(proto.Protocol)` class in the `bridgedb.git/scripts/get-tor-exits` script for an exmaple of how Twisted wants IO to be done). So because this IO is all blocking, and because of the hang bug, it never returns to BridgeDB's main loop, which is where the handlers for the SIGUSR1 and SIGHUPs signals are, which are required to restart BridgeDB when it receives new descriptors from the BridgeAuth.
    1212
    1313To be clear, none of this is a bug in Stem. It's all BridgeDB.