Jetty 12: Review SerializedInvoker.Link.getInvocationType()

[sbordet]

Jetty version(s)
12

Description
SerializedInvoker.Link.getInvocationType() currently returns hardcoded BLOCKING.
This is because a blocking task can be offered while a non-blocking one is running, so the thread running the non-blocking task may assume that the task currently running is non-blocking, but then executes a blocking one that was offered concurrently.

This strategy works, but assumes the worst case, which may result in unnecessary threads hand-overs, for example for HTTP/2 DATA frames, where an application could pass a NON_BLOCKING Runnable to Request.demand(Runnable).

Review whether we can improve on this logic, possibly having the thread offering the blocking task wait until previous non-blocking tasks are run.

[gregw]

If we change the AtomicReference to the tail a AtomicMarkableReference then the mark can indicate if the task returned from offer was blocking or not.

So we have 6 possible states when we offer a task (blocking or non_blocking (ignoring either for now)) to a serializer that is either empty, contains all non_blocking, or contains at least 1 blocking.

Tail	Offer Blocking	Offer Non-Blocking
Empty	return Blocking Link with Q marked Blocking	return Non-Blocking Link with Q marked Non-Blocking
Blocking	return null	return null
Non-Blocking	Add a new non-blocking Link to the Q, return a task that waits until task in Q in Q unblocks it an then it runs the task	return null

[joakime]

See also #11425

[gregw]

See also #12266

[lorban]

#12395 tackles this.