Both patches applied, thanks guys!

Olivier, I have a suggestion for this one :
On Thu, Aug 16, 2018 at 07:17:07PM +0200, Olivier Houchard wrote:
> From 90fc92f777772c6b47d88769bb73680702d7b8e6 Mon Sep 17 00:00:00 2001
> From: Olivier Houchard <ohouch...@haproxy.com>
> Date: Thu, 16 Aug 2018 19:03:02 +0200
> Subject: [PATCH 1/2] BUG/MEDIUM: tasks: Don't insert in the global rqueue if
>  nbthread == 1
> 
> Make sure we don't insert a task in the global run queue if nbthread == 1,
> as, as an optimisation, we avoid reading from it if nbthread == 1.
> ---
>  src/task.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/task.c b/src/task.c
> index de097baf7..e357bc169 100644
> --- a/src/task.c
> +++ b/src/task.c
> @@ -395,7 +395,8 @@ void process_runnable_tasks()
>                       state = HA_ATOMIC_AND(&t->state, ~TASK_RUNNING);
>                       if (state)
>  #ifdef USE_THREAD
> -                             __task_wakeup(t, (t->thread_mask == tid_bit) ?
> +                             __task_wakeup(t, (t->thread_mask == tid_bit ||
> +                                 global.nbthread == 1) ?
>                                   &rqueue_local[tid] : &rqueue);
>  #else

I'm pretty sure we'll get caught by this sort of stuff in the future
again. I think it would be safer to proceed like this :

     __task_wakeup(t, ((t->thread_mask & all_threads_mask) == tid_bit)

It should always be valid regardless of the number of threads. The same
could be done in task_wakeup().

I suspect we may have a similar issue with the fd cache applied to listeners
here :

   static inline void updt_fd_polling(const int fd)
   {
        if (fdtab[fd].thread_mask == tid_bit) {
                unsigned int oldupdt;

                /* note: we don't have a test-and-set yet in hathreads */


In this case the thread_mask might be larger than all_threads_mask and
we might fail this test. Or we may see that when threads exit and the
threads mask changes.

Just my two cents, both patches were applied anyway.

Willy

Reply via email to