It’s already running in an Executor which is why it’s a runnable.  The
Runnable defers the actual execution logic to the execute task function
which should be the one that is looping to perform all queued tasks from
the SSL Engine.

On Wed, Mar 2, 2022 at 3:51 AM Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Hi,
>
> an alternative would be to modify the execute_task method to become:
>
>      synchronized protected void execute_task(NextFilter next) {
>          Runnable task = null;
>
>          while ((task = mEngine.getDelegatedTask()) != null) {
>              try {
>                  if (ENABLE_ASYNC_TASKS && (mExecutor != null)) {
>                      mExecutor.execute(task);
>                  } else {
>                      task.run();
>                  }
>
>                  write_handshake(next);
>              } catch (SSLException e) {
>
> So here, we push the tasks into an executor to be processed concurrently.
>
> On 02/03/2022 07:05, Emmanuel Lécharny wrote:
> > Hi Jonathan,
> >
> > I wonder if using an executor to process SSLEngine tasks is useful at
> > all, considering that the execute_task method is synchronized:
> >
> >      protected void schedule_task(NextFilter next) {
> >          if (ENABLE_ASYNC_TASKS) {
> >              if (mExecutor == null) {
> >                  execute_task(next);
> >              } else {
> >                  mExecutor.execute(new Runnable() {
> >                      @Override
> >                      public void run() {
> >                          SSLHandlerG0.this.execute_task(next);
> >                      }
> >                  });
> >
> > and
> >
> >      synchronized protected void execute_task(NextFilter next) {
> >          ...
> >
> >
> > Also the execute_task will pull tasks from the SSLEngine - we may have
> > more than one, so it will loop on the tasks - and it's unlikely that we
> > will have more tasks to execute when exiting the execute_tasks method.
> >
> > The only benefit I can see is that the main thread will be freed for
> > other tasks - like processing another IoSession - while tasks are being
> > processed by another thread. And may be this is what was intended, but I
> > wonder iff we should not simply spawn a dedicated thread for that
> purpose.
> >
> > IMO, if we want to introduce an executor in the equation, it should be
> > done in the execute_task method, not in the schedule_task, it would
> > speed up the TLS processing, while also freeing the main thread fast
> > enough - even a bit slower than having the task loop being processed by
> > a dedicated thread.
> >
> > wdyt?
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Reply via email to