[civetweb] Interface for setting stack size and scheduler options

[Christian Mauderer]

Am Dienstag, 17. Mai 2016 21:07:46 UTC+2 schrieb bel:
>
>
>
> On Tuesday, May 17, 2016 at 7:50:02 AM UTC+2, Christian Mauderer wrote:
>>
>>
>> The solution with the *start_thread* callback is quite a different 
>> approach than my original one but it looks like a quite portable solution.
>>
>> Am Freitag, 13. Mai 2016 20:42:03 UTC+2 schrieb bel:
>>
>>>
>>> *int **start_thread**(**const struct mg_context ** ctx,* 
>>> mg_thread_func_t* func, *void ** param, *void *** handle, ... to be 
>>> defined*)* 
>>> {
>>>    stack_size <-- mg_get_option(ctx, "rtems_stack_size");
>>>    other_params <-- mg_get_option(ctx, 
>>> "rtems_whatever_options_you_need");
>>>
>>  
>> I'm  not sure if that works. If I interpret the source correctly, the 
>> following prevents any key in the options that is not in your list of known 
>> options:
>>   
>> https://github.com/civetweb/civetweb/blob/23266e11f4285ba9e608525ebb771062872099c9/src/civetweb.c#L12960
>>
>> With that, all parameters would have to come from another source. Am I 
>> wrong?
>>  
>>
>
>
> It's difficult to keep an overview with two discussion threads here and 
> additional threads at the RTEMS discussion forum.
>

Currently you can more or less ignore the thread on the RTEMS mailinglist. 
Except for the one comment that I already forwarded above, there haven't 
been any discussions regarding the interface. We only had a long discussion 
where to put the updated sources. Integrate them like mongoose or put them 
in a (currently not existing) vendor software repository. This problem 
still exists and I don't really have any project time left to solve it. So 
it quite possible won't be solved that soon.

My suggestion would be that we agree to an interface in one of the threads 
here and then I'll ask again for some feedback on the RTEMS mailing list. 
Eventually it would be useful to start a new thread with a matching topic 
and close this and the other one with a pointer to the new one?
 

> The main advantages of the *start_thread* callback are flexibility and 
> portability.
>

I see your arguments. You have a strong focus on portability between 
different systems with a big range of schedulers. So I agree that the 
flexible solution would be the best.
 

> It is correct, the 
> if ((idx = get_option_index(name)) == -1) ... return NULL 
> code in the link above 
> <https://github.com/civetweb/civetweb/blob/23266e11f4285ba9e608525ebb771062872099c9/src/civetweb.c#L12960>  
> will currently not allow to set any parameters. 
> This can be solved, either by an #ifdef, by a reserved prefix, ... don't 
> worry, this is a secondary problem.
> If we agree on the primary approach, this detail will not stop us.
>
>  So, all parameters can come from the same source.
>
>
So the primary approach would be the *start_thread* callback you mentioned 
above. If I interpreted it correct that would mean that the 
*mg_start_thread_with_id* would need an additional parameter to identify 
the kind of the thread (i.e. an enum). If the callback is set, it would use 
the callback to start the thread. Otherwise it would do the same as it does 
now. The callback would have to have the same parameters like 
*mg_start_thread_with_id* (including the new one that identifies the kind 
of thread). Anything else?

What about the *mg_start_thread* function? It seems that it is never used. 
Is that some kind of legacy support function?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160518/5f4f790e/attachment-0002.html>