Re: workqueue semantics [was Re: How to identify specific wait-state for a "DE" process?]

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Wed, Jan 06, 2016 at 11:38:00AM +0800, Paul Goyette wrote:
> On Wed, 6 Jan 2016, Taylor R Campbell wrote:
> 
> >  Date: Tue, 5 Jan 2016 21:48:42 -0500
> >  From: Thor Lancelot Simon <tls%panix.com@localhost>
> >
> >  You can probably use workqueues for this.  Looking at the manual page
> >  again for the first time in years, I think it's a little misleading --
> >  what I believe is meant by "A work must not be enqueued again until the
> >  callback is called..." is really "a work item must not be re-enqueued
> >  before it has been processed by the *func callback", not the alternate,
> >  crazy reading that would imply workqueues can only have one enqueued
> >  item at a time.
> >
> >Your reading of the man page is correct: it is the struct work, not
> >the struct workqueue *, that may not be reused until the callback is
> >run.
> >
> >(I'm not sure how this would help for pgoyette's application, though.)
> 
> I don't know how it would help, either.  The best I can think of is to have
> a periodic task run which checks to see if the file descriptor is being
> closed;  if yes, then the code could release the reference and wake up the
> condvar waiter.  But is this really a good thing to do?  And what would be
> an appropriate interval?

Why do you need a periodic task?  When you enqueue the work to release the
reference, the workqueue framework will run the callback function -- in a
different thread.  Then it can wake you up.  Isn't that what you wanted?

Thor