On 27 April 2017 at 03:49, Stuart Douglas <sdouglas_at_redhat.com> wrote:
> On Wed, Apr 26, 2017 at 9:30 PM, Greg Wilkins <gregw_at_webtide.com> wrote:
>
> > So keeping start (with it's bad name) is required.
> >
> > Execute is an additional semantic that makes async apps easier. I can
> > imagine applications that work out a result using multiple calls to start
> > and then call execute to write out the response so produced.
>
>
> +1
>
> Something we should clarify though is do tasks submitted through
> start() count as a 'thread dispatched by the container'. i.e. if I
> call start followed by execute() will the execute task wait for the
> start() task to complete before running?
>
>
Ah yes that does need to be clarified. I think that start is not mutually
excluded from any other thread. It's current contract remains the same -
ie to just anoint a runnable with classloader and permissions, but no
mutual exclusion.
So we should perhaps be very explicit about the difference and the dangers:
/**
* Execute a submitted {_at_link Runnable} task scoped to the associated
* request, either in a new thread, in a pooled thread, or in the calling
* thread, at the discretion of the Container.
* Unlike {_at_link#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 method but excluding any used by {_at_link
#start(Runnable)}.
* 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 task, so that it has all the capabilities and
* permissions of a container thread dispatched to the Servlet#service
method
* for this request.
*
* @param task the asynchronous task
*/
void execute(Runnable task);
/**
* Execute a submitted {_at_link Runnable} task scoped to the associated
* request, in a new thread\possibly from a managed thread pool.
* The container will propagate appropriate contextual information to the
* thread executing the task, so that it has all the capabilities and
* permissions of a container thread dispatched to the Servlet#service
method
* for this request.
* Unlike {_at_link #execute(Runnable)}, the tasks submitted to this method
may
* run concurrently with each other and with container threads calling the
* Servlet API for the associated request. Applications must take care to
* properly protect access to Servlet APIs that are not thread safe.
*
* @param task the asynchronous task
*/
void start(Runnable task);
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com