[civetweb] Interface for setting stack size and scheduler options

Mon May 2 08:39:04 UTC 2016

Am 27.04.2016 um 23:44 schrieb bel:
> 
> 
>     What do you think of the solution of ignoring parameters? 
> 
> 
> Ignoring parameters on a certain platform feels like
> "Error: parameter xyz does not work on platform ..."
> 
> If the parameter exists, it is supposed to work.
> 
>  
> 
>     Or alternatively: What about adding the configuration parameters
>     only if enabled with a special define. Something like
>     "ENABLE_EXTRA_SCHED_PARAMS"? 
> 
> 
> This is certainly a better way to do it.
> There are already some defines like USE_LUA, USE_DUKTAPE, USE_WEBSOCKET
> - if they are set, there are some additional config parameters.
> 
> However, the disadvantage of these defines: The number of different
> build configurations rises exponentially with the number of defines.
> Currently there are 192 combinations in the Travis CI environment
> (https://travis-ci.org/civetweb/civetweb/builds/126018705) - all are
> built and tested automatically. This already takes several hours.
> Probably one does not need to add all combinations of
> ENABLE_EXTRA_SCHED_PARAMS set/not set with all combinations of all other
> parameters.
> 

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?

>  
> 
>     The default make configurations just don't use this so the normal
>     user who uses the standalone executable would be save. Eventually
>     the define can be documented with some extra warning like "intended
>     for use in embedded systems only" so that the normal desktop
>     programmer knows that he should ignore it.
> 
> 
> Also desktop programmers can use them, if they know what they are doing.
> I just think end users should not change the parameters. In particular,
> the configuration for the pre-built executables available for download
> at SourceForge should not offer these configuration parameters.
> 
> 
> One important point is, civetweb already has two define values
> USE_STACK_SIZE and USE_MASTER_THREAD_PRIORITY to set stack size and
> priority. This is also a kind of interface for embedded developers
> already using civetweb. They just define then to the values they need in
> their Makefile, project file or whatever they use to build civetweb.
> For an existing project already setting USE_STACK_SIZE to some value, it
> might make a problem if this variable is no longer used. The build will
> not break, but the define is ignored - it is not impossible to do this
> if it is properly documented in the release notes. Still, if there is a
> way the existing defines are still working, this should be the preferred
> solution.
> There could be some rule like "define it to -1 to read the value from
> the configuration" ... this would be OK from the compatibility point of
> view. Probably there is a better way - I need to think about it.
> Maybe one can use the current define values as the default values for
> new configuration parameters stack-size and thread-priority.

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.

> 
> Back to my idea with the callback:
> The callback is the most flexible way to do something within a new task.
> You could set variables in the thread local storage, you could change
> the priority - but you can not change the stack size, since this
> parameter must be known before the thread is created, and I would call
> the callback from the new thread. A callback might still be valuable for
> other purposes, but not for setting the thread size.
> I read above a callback would yield in the configuration being split up
> into two parts. That's not necessarily true, since the callback can
> access user parameters set when calling mg_start. A user parameter may
> point to a configuration table that stores first parameters for the
> callback followed by the predefined civetweb parameters, so all
> parameters can be stored in the same table.
> 

Would that mean that you would like to see both - the parameters and a
callback - to be added?

> 
> Let's get back to the requirements:
> 
> You need to set:
> - the stack size of all worker threads
> - the stack size of the master thread
> - the stack size of the timer thread
> - the stack size of websocket client worker threads
> - the priority (including scheduler) of the worker thread
> - the priority (including scheduler) of the master thread
> - the priority (including scheduler) of the timer thread
> - the priority (including scheduler) of client worker threads
> 

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.

> scheduler would be SCHED_OTHER, SCHED_FIFO and SCHED_RR?
> Anything else?

There is also SCHED_SPORADIC. See
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sched.h.html.
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.

Kind regards,

Christian Mauderer

-- 
--------------------------------------------
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.