[civetweb] Interface for setting stack size and scheduler options

[Christian Mauderer]

I've got some feedback on the RTEMS mailinglist (part of 
https://lists.rtems.org/pipermail/devel/2016-April/014729.html):

Am 27.04.2016 um 02:07 schrieb Chris Johns:
>> I already contacted the civetweb author regarding two of the patches.
>> One was a new one (civetweb now uses a timegm function that we don't
>> have: https://github.com/civetweb/civetweb/pull/298).
>>
>> The second one was a more complex one that _could_ lead to maintenance
>> effort: We (to be exact: I) added some paramters to mongoose to
>> influence stack size and scheduling. The maintainer of civetweb wasn't
>> really enthusiastic about the way of the integration. He would prefer
>> another interface. I tried to invite the RTEMS mailinglist into the
>> discussion but till now I didn't get any responses:
>> https://lists.rtems.org/pipermail/devel/2016-April/014621.html
>> https://groups.google.com/forum/#!topic/civetweb/_Mul9PxgpBE
> 
> I see. If there exists a risk for Windows, Linux or any platform related
> configuration parameter getting bad values, why not force the value, or
> ignore the user setting, or raise an error on those platforms a
> parameter setting does not work on. This model is consistent, easy, and
> allows a finer per platform control of all parameters. The documentation
> for configuration is in a single location.
> 
> I have been looking after a mongoose set up for a client someone else
> set up. There has now been a couple of sets of eyes looking at the
> configuration and making minor tweaks. If there was another call-back,
> or overloaded define interface being used we would never have found it.
> 
> It would be a shame to add a call-back interface because the
> configuration becomes split and integration becomes disjointed. Also
> these days I prefer weak symbols over call-backs. Overloading the define
> with a call-out is tricky and hidden and it leaks internal details as a
> published interface.

What do you think of the solution of ignoring parameters? Or alternatively: 
What about adding the configuration parameters only if enabled with a 
special define. Something like "ENABLE_EXTRA_SCHED_PARAMS"? 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160427/71deab01/attachment-0002.html>