Constructor of msgpackrpc.Session class has an optional argument loop=None. When loop is not specified, new Loop will be automatically created in the constructor.
However, as automatically-created Loops are not closed automatically, it uses more file descriptors than expected. This becomes an issue for clients that connects/disconnects frequently.
I think automatically-created Loops should be closed (i.e., session._loop._ioloop.close()) when its associated Session is closed.
I have two ideas:
- If
Loop instance is not specified by user (i.e., automatically created in Session constructor), close the Loop when session.close() method is called.
- Add
close_loop=True to the Session constructor argument. Close the Loop only if close_loop is set to True when session.close() method is called. This behavior is similar to closefd option of io.FileIO.
In addition, it is better to add close() method to msgpackrpc.Loop class, to allow users to close the internal tornado IOLoop.
Constructor of
msgpackrpc.Sessionclass has an optional argumentloop=None. Whenloopis not specified, new Loop will be automatically created in the constructor.However, as automatically-created Loops are not closed automatically, it uses more file descriptors than expected. This becomes an issue for clients that connects/disconnects frequently.
I think automatically-created Loops should be closed (i.e.,
session._loop._ioloop.close()) when its associatedSessionis closed.I have two ideas:
Loopinstance is not specified by user (i.e., automatically created inSessionconstructor), close the Loop whensession.close()method is called.close_loop=Trueto theSessionconstructor argument. Close the Loop only ifclose_loopis set to True whensession.close()method is called. This behavior is similar to closefd option of io.FileIO.In addition, it is better to add
close()method tomsgpackrpc.Loopclass, to allow users to close the internal tornado IOLoop.