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

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  Is there a particular reason file descriptors are closed in
ascending order?  Traditionally, file descriptors 2, 1 and 0 are always in
use and it seems like it might be a good idea to have those be the last to
get closed.  I've seen some applications that close all their descriptors
in descending order.   I thought that was odd, but I think Paul just came
up with a good reason to do such a thing.
-Brian

On Jan 6, 11:38am, Paul Goyette wrote:
} Subject: Re: workqueue semantics [was Re: How to identify specific wait-st
} 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?
} 
} 
} +------------------+--------------------------+------------------------+
} | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
} | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
} | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
} +------------------+--------------------------+------------------------+
>-- End of excerpt from Paul Goyette