[civetweb] Interface for setting stack size and scheduler options
christian.mauderer at embedded-brains.de
Tue May 3 08:03:44 UTC 2016
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.
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
> All parameters passed to mg_start as configuration options are strings
> 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
>> 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.
>> 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
> 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
>> There is also SCHED_SPORADIC. See
>> 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
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
> 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
I see your point and will put some thoughts into it.
embedded brains GmbH
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.
More information about the devel