On Mon, May 9, 2016 at 6:31 PM, Benjamin Walsh
<benjamin.walsh(a)windriver.com> wrote:

In the current patchset there is a global workqueue, but it's labeled as
sensor-specific. I don't see a problem with making it generic. If I
do, sensors could use it, as well as any other subsystem that needs to.

Using the same fiber for both callout and workqueue is probably a good
idea for saving memory.

I'll also take a stab at implementing delayed work, let's see what the
results look like.

That's what the proposed callout API is doing though. Take a look at it
before duplicating work...

Lets get the workqueues merged asap then I can add the delayed version
on top of it. I believe this shows that we need to be a little more
proactive about features such as this, merging things quickly and fix
comments with other patches should give us a bit more agility.

OK, but I don't think the two implementations will share much except the
system fiber that the callbacks will run in. There is not much that is
similar between your callout implementation and the workqueue
implementation. I was pointing Vlad to your implementation to show him
what were the ramifications for adding a delayed work framework.

Actually submitting work with a fifo is pretty similar, the delayed
version will probably only need a _nano_timeout and the workqueue
pointer so we can submit once it timed out.

I'll wait for your implementation before commenting more, but yes, the
only thing that I saw was similar between the two was that the fiber
could be shared, and of course, that means that both the work queue and
the callout systems schedule work by adding it to the fifo the fiber is
waiting on.