[civetweb] Interface for setting stack size and scheduler options

[Christian Mauderer]

Am Sonntag, 22. Mai 2016 23:26:07 UTC+2 schrieb bel:
>
>
>
> On Sunday, May 22, 2016 at 11:04:44 AM UTC+2, Christian Mauderer wrote:
>>
>>
>> I created a draft for a callback. It's not worked out and only thought as 
>> a basis for further discussions:
>>
>>   
>> https://github.com/c-mauderer/civetweb/commit/380db13ad3c6c504002ba508605ced6d8ab7d550
>>
>
> I just had a look at the interface (civetweb.h), but not the 
> implementation yet:
>
>    - Please do not change the typedef for mg_thread_func_t, this is a 
>    compatibility issue (see also below).
>
> OK. Like I said: It was only quickly hacked together change as a basis for 
further discussion so this one slipped.

>
>    - 
>    - You should not use enum types (like you did in your change to init_thread) 
>    but only enum constants (like in your start_thread) in the interface.
>    So you should remove the name, like
>    enum */* no name here */* { TIMEOUT_INFINITE = -1 };
>    
> I'll change that. Is there any special reason for that (like C standard 
compatibility issues) or is it just the coding style? 

>
>    - 
>    - Since we need to replace *mg_start_thread_with_id*, there must be an 
>    additional output parameter *thread_id* in the *start_thread* 
>    callback. This parameter is later used in *mg_join_thread*, to wait 
>    for the thread to terminate. I think an additional callback for that is 
>    required as well. If thread creation is "outsourced", the code that took 
>    responsibility for thread creation should be able to handle termination as 
>    well, if this is required for a non-Windows-non-pthread threading system. 
>    In theory it could be done internally using an additional waitable object 
>    (event, mutex, ..), but I think this is a rare case that should not make 
>    the Windows and Linux code more complicated, so let's allow to handle it 
>    externally.
>    
>
> I assume you think of the *pthread_t *threadidptr*. I have overseen this 
one. Should this be a generic pointer (*void **) or can we use the *pthread_t 
** pointer? I think *pthread_t* is problematic on windows?
 

>  
>
>> I had the following problems:
>>
>> - The thread has a different return type for windows and for POSIX. It 
>> seems that no thread is really using the possibility to return anything. 
>> Currently I removed the return and just set it to void. I would expect that 
>> this leads to warnings when compiling the code. How could we handle this?
>>
>
> We already have a definition in civetweb.h:
> *typedef void *(*mg_thread_func_t)(void *);*
> This is already a part of the public interface, so it must not be changed 
> unless there are compelling reasons - style preferences are not compelling 
> reasons.
>
> I didn't change it due to style preferences. I changed it due to the 
different return type on windows. The *_beginthreadex* call used on windows 
returns an unsigned while the POSIX functions return a void pointer. Both 
results haven't been used and just needed some extra #ifdefs. But like I 
said, it is quite likely a problem anyway so I will look into another 
solution.
 

>
> - The *struct mg_context* is declared in the civetweb.h but defined in 
>> civetweb.c file. So It could be tricky to access any context fields from 
>> inside a callback (e.g. for getting parameters). How is this handled in 
>> other callbacks? Did I overlook something?
>>
>
> See civetweb.h:
>
> CIVETWEB_API const char **mg_get_option*(const struct mg_context *ctx, 
> const char *name);
>  
> CIVETWEB_API void **mg_get_user_data*(const struct mg_context *ctx);
>
>
Thanks for the hint. Rather than using the context directly some helper 
functions are used. It's definitively a better solution than some exposed 
internal structures would be. I just thought into a wrong direction.

I'll try to update the patch in the next few days and will report back with 
an improved version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160523/48cafdbb/attachment-0002.html>