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?
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
