Never block waiting for reserved thread.
Dump reserved thread stack if it does not make the rendezvous

…95-ReservedThreadExecutor

fix warnings

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

avoid waiting 1s

If a reserved thread does not rendezvous, put it back on the bottom of the stack.

Even more paranoid checks:
 + test if an missed offer was for a thread that removed itself from the stack
 + test if a reserved thread is already on the stack before adding it.

Even more paranoid checks:
 + try to poll after remove to check for race in remove

Even more paranoid checks:
 + try to poll after remove to check for race in remove

This is a new approach to #6495.    A call to offer must never block, nor even yield, since to do so give an opportunity for the allocated CPU core to change, defeating the whole purpose of the class.

There is also some reasonable level of diagnostic warnings if a reserved thread misses too many offers consecutively, based on tracking the state of the reserved thread.

Use MAX_VALUE rather than -1 as the stopped marker value.

Remove the stack data structure entirely.  ReservedThreads all poll the same SynchronousQueue and tryExecute does a non blocking offer.

Added test for busy shrinking

Remember last time we hit zero reserved threads

updates from review

fixed busy idle

fixed busy idle

simplified stop

updates from review

updates from review

Signed-off-by: Greg Wilkins <gregw@webtide.com>

Signed-off-by: Greg Wilkins <gregw@webtide.com>

…:eclipse/jetty.project into jetty-9.4.x-6495-ReservedThreadExecutor3

updates from review

simplified tryExecute

updates from review

updates from review

updates from review