[Ur] callbacks from C FFI (again)

[Adam Chlipala]

On 12/30/2013 04:49 AM, Sergey Mironov wrote:
> Using tasks, we may extract a
> callback url from some ffi-specific queue, but currently urweb doesn't
> provide a method to 'call' it safely (I assume, [redidrect] doesn't
> work in tasks). That is why I think this way still requires some
> non-trivial server-side modifications..
>    

What's wrong with using code like this to call the URL, using the 
context of the FFI function where this action happens?
     uw_get_app(ctx)->handle(ctx, uri);
You literally would not need a single line of additional code to make a 
callback.  Are you just suggesting that this operation should be made 
available in the standard library, so that it can be used without 
writing any FFI code?

Actually, now I'm thinking of an angle that I'm surprised I missed 
before: if tasks are OK, why involve the FFI at all in callbacks?  You 
can orchestrate callback plumbing entirely within Ur/Web code, can't 
you?  For instance, a task polls an SQL table and calls a function with 
each row as an argument, deleting all the rows afterward.

To me, it sounds like this is a 100% acceptable solution if a reasonable 
polling interval can be found for periodic tasks in an application.  You 
call the FFI only to, e.g., initiate a download and then insert a row 
into a database table (using code that need have nothing to do with 
Ur/Web).  You can also use a custom in-memory data structure and then 
only make FFI calls to manipulate that structure, not to do anything 
with callbacks.

In general, I'm hesitant to invest now in implementing a very general 
mechanism, if periodic tasks seem to be suitable for the specific 
applications you have in mind now.

> And here comes your point about CGI. It really does make the picture
> simpler. I think the callback handler from my patch may be moved to
> the FFI code now.   Almost all functions being used  - uw_reset,
> uw_begin, uw_commit, uw_rollback, uw_set_deadline all live in urweb.h
> and AFAIK are 'public'. So FFI side would require only one function
> from request.c:   uw_request_new_context .  Currently, we should
> provide it with the the id, the uw_application and loggers, that is
> why it is hardly possible to make it public. So I suggest writing a
> new method for cloning existing context. It's signature may be
>    

This all sounds rather baroque.  I would think a preferable mechanism 
would be a new kind of _triggerable_ task, where a thread sits there 
idle until an FFI call like uw_trigger_task("name_of_task") causes the 
code associated with the task to run once (in its own thread).  For most 
applications of delayed callbacks, I bet periodic tasks are sufficient 
and offer performance almost indistinguishable from any alternatives, 
but triggerable tasks could be the simplest way to handle future 
performance issues.

What do you think?

In any case, it sounds like we still have enough thinking to do about 
these architectural decisions that I shouldn't delay the next Ur/Web 
release.