While looking at adding a thread to handle NLM blocked lock polling on FSALs that don't support async blocking locks, I noticed there's a lot of complexity in the thread fridge and a lot of different users each with their own pool (some pools with only 1 thread).
I think it might be worth examining how we use the thread fridge and look for ways to simplify it, and also make sure we are making the best use of threads. We have a number of uses of a "worker thread" model where a pool of threads looks on a queue for work to do. One question is if every one of these uses needs its own queue. The nfs_worker_thread threads probably do benefit from being their own pool and queue, but do all the other uses. Then there are some threads that wake up periodically to do work that is not exactly queued (the reaper thread for example). It's not clear if these threads avoid any wakeup at all If there is not any work to be done. Then there are some threads that live to sit blocked on some system call to wait for work to do. These threads particularly don't make sense to be in a thread pool unless they block intermittently (for example the proposed threads to actually block on locks). For shutdown purposes, we need to examine if any of these threads is not able to be cancelled, and also find the best way to cancel each one (for example, a thread blocking on an fcntl F_SETLKW can be interrupted with a signal). I also wonder if the multi-purpose threads have too many locks. It looks like fridge has two separate mutexes. Typically, when I implement a producer/consumer queue from scratch, I protect the queue with the same mutex as is paired with the condition variable used to signal the worker thread(s). Cancelling the thread can either be accomplished with a separate "cancel" flag (also protected by the mutex) or a special work item (perhaps put at the head of the queue instead of the tail, depending on if you want to drain the queue before shutdown or not). Any major changes here are 2.5 items, but it's worth starting a discussion. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
