Moved the try-except block from submit to a new post_request function nested inside submit, so that it works as a target when creating a new Thread. This thread doesn't block the calling thread (so that a new submission can be made from the main thread), instead a max_queue_depth attribute that defaults to 128 sets the upperbound limit of a Queue object, which can block if necessary until a free slot is available. When submit is called, given that the logger's queue attribute is not None, the corresponding msg is put in the queue and a new post_request thread is started. After each response, the first item in the queue is removed (NOTE: the first thread to have a response will perform the next dequeue operation, thus the item returned from the queue might not necessarily match the msg passed to that particular thread)
I assumed that the queue attribute of the BaseLogger object was intended for this purpose, but I'm not sure that this is the case. Please, let me know if something like this is what you had in mind @RobDickinson
Moved the
try-except
block fromsubmit
to a newpost_request
function nested insidesubmit
, so that it works as a target when creating a newThread
. This thread doesn't block the calling thread (so that a new submission can be made from the main thread), instead amax_queue_depth
attribute that defaults to 128 sets the upperbound limit of aQueue
object, which can block if necessary until a free slot is available. Whensubmit
is called, given that the logger'squeue
attribute is notNone
, the correspondingmsg
is put in the queue and a newpost_request
thread is started. After each response, the first item in the queue is removed (NOTE: the first thread to have a response will perform the next dequeue operation, thus the item returned from the queue might not necessarily match themsg
passed to that particular thread)