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