Just enabling or disabling logging falls short of the power of
interfaces of go. A user is forced to either accept the logging to
stderr in the format defined by xgb or disable logging alltogether. By
exporting the logger, we can actually let the user decide where to log
in what format.
goofing here.
What I'd personally like to do is just use an "infinite" channel. That
is, push the limit of how many events can be processed to the machine
and not set an artificial limit in XGB. Some day...
and falling back to a blocking send inside a goroutine.
This really needs to be fixed. The situation only arises when events are
sent and aren't pulled off the channel using {Wait,Poll}ForEvent.
Namely, if the event send blocks, the entire program will deadlock.
Using a goroutine is not ideal because we lose a guarantee of order:
that events are processed in the order of their arrival. However, it
seems OK as a temporary band-aide for a situation that probably doesn't
arise too often.
What I need to do is implement a dynamic queue. Here is a reference
implementation: http://play.golang.org/p/AiHBsxTFpj
Axel Wagner
Andrew Gallant
Andrew Gallant (Ocelot)