[PATCH] D48240: Try again to implement a FIFO task queue

[Zachary Turner via Phabricator via llvm-commits]

zturner added a comment.

In https://reviews.llvm.org/D48240#1134655, @chandlerc wrote:

> Before I dig in too much to the code, I want to better understand the underlying goal...
>
> The core primitive here is a *serialized* task queue from what I understand...
>
> Is it important that it starts a separate thread and eagerly (as opposed to lazily) processes the enqueued tasks?


Yes

> If so, would it be a problem for the thread(s) used to be shared with other work at times (provided the synchronized aspect is preserved)?

Depends what you mean by shared.  Certainly you can queue up any work you want here, so if your jobs are A, C, and E, and someone else's jobs are B, D, and F, then queueing up A, B, C, D, E, F should work just fine.

The motivation for this is imagine you're writing an application that segments its work into different threads.  For example, you might have a UI thread, a file i/o thread, a network thread.  Work that changes the state of a UI element has to happen on the UI thread.  Work that physically waits on a socket has to happen on the network thread, etc.  This is a pretty common architecture for certain types of applications.  Another example might be if you were writing a debugger which was debugging N processes simultaneously, and due to various OS restrictions, each of these N processes was being debugged by a separate thread.  The application controlling all this would like to not have to deal with synchronization, but if each of these threads just said "wait for something to happen, then invoke a callback" the callback would happen on an arbitrary thread context and the user would be responsible for synchronizing all of this.  It's nice to be able to guarantee something like "the callback always gets invoked on the same thread" to simplify the user's life.

LMK if this makes sense.


https://reviews.llvm.org/D48240