The threads parameter is unused in Corosync 2.0. In corosync 1.y, there was threading used throughout the code base. It resulted in race conditions and incorrect behavior, so threading was compeltely removed in 2.0.
Threads are an anti-pattern and evil, and should never be used in proper software IMNSHO :) Regards -steve On Wed, Jun 3, 2015 at 7:02 AM, Ulrich Windl < [email protected]> wrote: > >>> Jan Friesse <[email protected]> schrieb am 03.06.2015 um 13:49 in > Nachricht > <[email protected]>: > > Ulrich Windl napsal(a): > >> Hi! > > Hi! > > >> > >> I have a question on the "threads" parameter (How many threads should be > > used to encypt and sending message): > >> > >> How can encryption of one message be distributed to multiple threads? If > > there are multiple messages to be created and sent sequentially, how > would > > the use of multiple threads to encrypt them improve the situation. > >> > >> Is the code really free of race conditions? > > > > Nobody knows (how can that be proved? > > Assuming mutual exclusion primitives (on the hardware) work OK, you can do > that by careful design I guess. > > > Because if you can prove it, go > > ahead for Nobel prize), but it's for sure not very common (= almost > > nobody use that) code path, so I would say probably no (that's why > > corosync 2.x doesn't have threads at all). > > You are not going into details with the design (my question), but I guess > if you allocate some memory under mutual exclusion from a shared pool, and > each thread only works on that allocated memory, there should not be any > race condition. > > So whats' the use of a threads parameter if corosync does not use > threads??? > > Ulrich > > > > _______________________________________________ > discuss mailing list > [email protected] > http://lists.corosync.org/mailman/listinfo/discuss >
_______________________________________________ discuss mailing list [email protected] http://lists.corosync.org/mailman/listinfo/discuss
