Dne 28.11.2016 v 17:07 Benjamin Marzinski napsal(a):
On Mon, Nov 28, 2016 at 11:05:29AM +0100, Hannes Reinecke wrote:
Hi Junhui,
Tricky bit would be to figure out _when_ to stop uevent processing and
calling 'ev_add_path'.
I guess we'd need to make 'ev_add_path' running in a separate thread;
that way we'd be putting pressure off the uevent processing thread and
the whole thing should be running far smoother.
I still think that we don't need to force a wait here.
uevent_dispatch() already pulls off all the queued events in a batch. We
could just merge over the batch that we are given. This has the nice
property that when uevents aren't coming in a storm, we quickly process
the next event, and when they are, the further multipathd gets behind, the
larger the list it will merge over.
It's worth to mention at this point - libdevmapper 1.02 is NOT library
with multithread support - there is 'certain' limited set of thread-safe
functions, but for sure not a whole library.
So any threaded usage of libdevmapper.so would likely require mutex against
access to do library code.
Regards
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
