diskqueue: support a callback when the disk queue is empty #21
Conversation
| } | ||
|
|
||
| // New instantiates an instance of diskQueue, retrieving metadata | ||
| // from the filesystem and starting the read ahead goroutine | ||
| func New(name string, dataPath string, maxBytesPerFile int64, | ||
| minMsgSize int32, maxMsgSize int32, | ||
| syncEvery int64, syncTimeout time.Duration, logf AppLogFunc) Interface { | ||
| syncEvery int64, syncTimeout time.Duration, logf AppLogFunc, cb EmptyCallback) Interface { |
There was a problem hiding this comment.
I have quibbles with the naming here ... the type EmptyCallback func() initially sounds to me like it is describing the callback taking no arguments and returning nothing. I lean towards just queueEmptyCB func() (no extra type).
It's a bit annoying that we have to break compatibility when adding optional arguments here. Already did that for logf though, and not sure want to redesign with a DiskQueueOptions struct or similar, right now.
|
I thought i would need this feedback loop - but i'm not currently using it in nsqio/nsq#1305 (still a WIP so somewhat subject to change) - that means I might just end up closing this. |
| @@ -647,6 +652,9 @@ func (d *diskQueue) ioLoop() { | |||
| count++ | |||
| // moveForward sets needSync flag if a file is removed | |||
| d.moveForward() | |||
| if d.depth == 0 && d.emptyCallback != nil { | |||
| d.emptyCallback() | |||
There was a problem hiding this comment.
There is a risk that this callback will impact performance if this call is slow. Should it be called in a go routine?
|
感谢您的来信，我尽快回复您！
|
|
Another question, was polling |
This supports nsqio/nsq#1305