[civetweb] Interface for setting stack size and scheduler options

[Christian Mauderer]

Am 02.05.2016 um 20:35 schrieb bel:
> 
> 
> On Monday, May 2, 2016 at 10:39:13 AM UTC+2, Christian Mauderer wrote:
>> I agree that eventually not all variations have to be tested. It's only
>> a challange to identify the irrelevant ones.
>>
>> Does the Travic CI allow to exclude certain combinations?
> 
> It works by defining all configurations that should be build.
> The build configuration explicitly lists all of them, so it already has
> more than 500 lines
> (https://github.com/civetweb/civetweb/blob/master/.travis.yml#L25 to
> https://github.com/civetweb/civetweb/blob/master/.travis.yml#L592) ...
> but I create the build configuration with a script anyway.
> 
> 
>> In my patch set, I used the values as default for the new parameters. It
>> needed some preprocessor magic to convert a number to a string but it
>> should work in theory.
> 
> I'm not sure what you mean.

https://github.com/civetweb/civetweb/pull/297/files#diff-942b175a4f5673b8f0ce6c0ab2fc2932R1195

I converted the current USE_STACK_SIZE to a string and used it as
default for the parameter. I think something similar should be possible
for priority.

> 
> All parameters passed to mg_start as configuration options are strings
> (see
> https://github.com/civetweb/civetweb/blob/master/include/civetweb.h#L243).
> For every option that is not a simple number or file path, it needs to
> be discussed how the options are mapped to the string.
> The thread priority is an operating system dependent parameter: For
> Linux it needs to specify a scheduling policy and a priority number, for
> Windows NT there are (I think) 7 values, for Win CE I think 100, ...
> 

I'm not sure how well I can integrate Windows options. I don't really
know the interface. Would it be acceptable if the additional options are
POSIX-only? Eventually I could add something like the following to give
a hint to someone who is trying to use it:

  #if defined(_WIN32) && defined(ENABLE_EXTRA_SCHED_PARAMS)
  #error ENABLE_EXTRA_SCHED_PARAMS is not implemented on Windows systems
  #endif

> 
>> Would that mean that you would like to see both - the parameters and a
>> callback - to be added?
> 
> Currently I think both is required sooner or later.
> This does not mean you have to do both.
> 

OK.

> 
>> I'm not sure if it is really necessary to set them to different values
>> for each kind of thread. Currently my patch used only one set of values
>> for every thread started with mg_start_thread. But it would surely add a
>> maximum of flexibility if every thread can be influenced. So it would be
>> nice.
> 
> Years ago, tests showed some systems work better if the master thread
> has a slightly higher priority than the worker threads.
> I did not re-test it recently, but I think nothing has changed in the
> fundamental structure. So from my point of view, it is still required.
> 

OK. That is an argument for it. So we need multiple options. Something like
  --worker-thread-opts=R20
  --timer-thread-opts=R21
  --master-thread-opts=R22

> 
>> There is also SCHED_SPORADIC. See
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sched.h.html
> <http://www.google.com/url?q=http%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F9699919799%2Fbasedefs%2Fsched.h.html&sa=D&sntz=1&usg=AFQjCNF-KxEBtbNAsZHHyC7kf4nystRy7A>.
> 
>> But this might is not available on every system. Therefore in my patch I
>> used some `if defined(...)` checking for some _POSIX_... defines to
>> protect it.
> 
> 
> SCHED_FIFO and SCHED_RR have one priority value - for Linux usually
> between 0 and 99 with 99 as the highest priority.
> SCHED_OTHER has the nice value
> (https://en.wikipedia.org/wiki/Nice_%28Unix%29) - from -20 to +10 with
> -20 as the highest priority.
> So basically it's just one number to configure the priority for these
> three schedulers.
> A priority string like F20, R10, O-6 would do to configure scheduler and
> priority.

That form of string reduces the number of necessary arguments but
increases the parsing effort. But I think that should be acceptable.
Eventually we should use longer strings like "FIFO20" instead. This
would increase the readability.

> From what I read on SCHED_SPORADIC
> (http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html#Sporadic_scheduling),
> there are a lot of parameters to set the priority: priorities N and L,
> times C and T, in addition the maximum number of pending replenishments.
> So a priority string would need to be like S40/3/20/100/1.
> If we just use a callback for the priority, we would not need so many
> parameters.
> 

I see your point and will put some thoughts into it.

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.