[Bro-Dev] 0MQ security considerations

[Adam J. Slagell]

On Jul 28, 2011, at 10:01 AM, Matthias Vallentin wrote:

>> We don't know how many cores the user will have and how many are
>> virtual (hyperthreading). Due to the direction hardware is heading, I
>> think if we estimate and hard code it in the design, it will soon be
>> an underestimate. Therefore, I would probably err on the side of more
>> threads than is typical in a server today when designing a
>> multi-threaded architecture.
> 
> One way to get around this is to just have a command line switch that
> specifies the number of threads to use in total. This would override the
> default concurrency level as detected by the application (i.e., the
> number of cores exposed by the OS). The applications than somehow
> internally distributes the number of available threads over the
> asynchronous components.
> 
> In fact, one often uses a slightly tweaked ratio with a little more
> threads than what the hardware exposes, as it achieves better
> saturation. (I guess that's what you mean by "err on the side of more
> threads.")

It wasn't clear to me whether or not the number of threads was really defined by the architecture. If there is always more work that you can give to more threads, then this works.