On 26/04/17 07:22, Greg Wilkins wrote:
>
>
> On 26 April 2017 at 00:35, Stuart Douglas <sdouglas_at_redhat.com
> <mailto:sdouglas_at_redhat.com>> wrote:
>
>
> I agree that this would be very useful, although I don't like the name
> (but I can't think of a better one off the top of my head).
> With regards to the 'which is assumed to be a short lived, preferably
> non blocking, method.' part are you expecting that this will be run in
> an IO thread? Otherwise I don't really see any need for this
> restriction.
>
>
>
> I think for the name, we should just use execute(Runnable) and then we
> are giving a standard API to the containers executor. In fact we
> could either just make AsyncContext extend Executor or perhaps just have
> a method on AsyncContext:
>
> /**
> * Get an Executor that serially executes submitted {_at_link Runnable}
> tasks scoped to
> * this request, either in a new thread, in a pooled thread, or in the
> calling
> * thread, at the discretion of the Container.
> * Unlike AsyncContext#start(Runnable), the container guarantees that
> * the task will not be executed concurrently with any other thread
> * dispatched by the container for the associated request including others
> * executed via this Executor. Note that long running or blocking tasks may
> * cause execution of Servlet API callbacks to be delayed until after they
> * complete.
> * The container will propagate appropriate contextual information to the
> * thread executing the tasks, so that they have all the capabilities and
> * permissions of a container thread dispatched to the Servlet#service
> method
> * for this request.
> * @return an Executor that will serially execute submitted {_at_link
> Runnable}
> * tasks scoped to this request,
> */
> Executor getExecutor();
I'd prefer execute(Runnable) as that means we don't have to expose an
executor to the application.
Is adding the 'one thread at a time' restriction to
AsyncContext#start(Runnable) not an option? Or does that put too much of
a restriction on existing applications?
Mark