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.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel