[Ur] callbacks from C FFI (again)

[Sergey Mironov]

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. The interface is:

(1)
int st_init(int _nthreads, struct loggers *ls);
void st_join(void);

(2)
void st_loopback_enqueue(const char *url);

(3)
typedef void* (*st_thread_fn)(void*);
int st_create(st_thread_fn fn, void *data);

(4)
typedef void* (*st_thread_fat_fn)(struct uw_context*, void*);
int st_create_fat(st_thread_fat_fn fn, void *data);
void st_loopback(struct uw_context*, const char *path);

Group (1) is a standard init/uninit pair. I've added the calls to all three
http.c, fastcgi.c and cgi.c frontends. I'm not sure if cgi.c will work correctly
or not on long-running tasks since the handler process will wait for their
completion.

Function (2) posts the loopback request to some worker thread inside
srvthreads.c. Actually it starts the pool of workers on first call.
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?

Functions (3) and (4) never called by server, they are for C FFI libs. Group
(3) is for creating a lightweight thread without associated uw_context. The
difference between (3) and pthread_create is that the server knows about threads
created by (3) and will wait for them before exiting. It may be vital
for cgi-mode, but
again, I didn't check how does it work yet.

Function st_create_fat (4) creates 'fat' threads with their own uw_context.
st_loopback_inplace may then be used to launch a transaction and handle the url
in the current thread. The good thing about it is that the user may code some
effectful operation _before_ the transaction and thus save it from potential
restarting.  But if I understand you correclty, there is a dangerous place
here.  According to what you have said earlier about transactions and deadlocks,
it is not safe to call st_loopback from any other place since uw_begin wants
uw_context with no transaction running. Am I correct here? Should I add some
protection against already running transactions into st_loopback?

Could you please review the st_loopback function and check the transaction
handling?  Meanwhile, I'm going to write an FFI lib demonstrating the new
functionality.

Regards,
Sergey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1_of_1_Add_support_for_server_side_threads_accessible_through_C_FFI.patch
Type: text/x-patch
Size: 22813 bytes
Desc: not available
URL: <http://www.impredicative.com/pipermail/ur/attachments/20131218/97ea0967/attachment-0001.bin>