[Ur] callbacks from C FFI (again)

[Adam Chlipala]

On 12/18/2013 02:46 PM, Sergey Mironov wrote:
> Hi. I've done some work regarding C callbacks, hook the app->handle
> as you suggested. The patch is rather big, but I think it handles the problem
> nice now. Basically, it adds ./src/c/srvthreads.c which does two things: a)
> manages a number of permanently-running worker threads to handle
> st_loopback_enqueue calls (see below), and b) manages a list of threads created
> by user.

Could you remind me of your use case for this functionality?

Why isn't it sufficient just to start a periodic task that runs one or 
all tasks from a queue of URI strings every second?  You would need only 
a tiny amount of FFI code (and no modifications to the base Ur/Web 
distribution) with that approach.

> Here I have a question:
> what does 'id' argument of
> uw_context uw_request_new_context(int id, uw_app *app, loggers *ls)
> do? Is it safe to keep several threads sharing same id?
>    

First, a meta response: the whole request.h interface was not intended 
to be exposed for use in FFI code.  It's really meant for internal 
Ur/Web stuff.

Second, the 'id' argument is important for generating [source] values, 
and I wouldn't recommend any change that stops it from being unique 
across server threads.

I saw the other questions in your message, which I'll return to 
answering if I become convinced that the approach you're following makes 
sense against the baseline of using periodic tasks.


A few other comments on your patch:

General C code shouldn't assume that the variable uw_application 
exists.  Everything is implemented to work even when multiple distinct 
applications run in one Ur/Web process, though I never released the 
(working) code for doing that.

Why does your modified uw_request_context() take both app and loggers as 
arguments, when the latter implies the former?