[Ur] callbacks from C FFI (again)

[Sergey Mironov]

> By "a bit too idealistic," do you mean that, at the moment, you don't have
> in mind an application where one-second latency poses a practical problem?
> I imagine it would also be easy to add support for periodic tasks with
> subsecond periods.
>
> For your downloader example, I don't see why a 1-second period (or N
> milliseconds period, which would be easy to add) wouldn't be just fine, if
> downloads take long enough to be worth spawning background jobs.
>
> Sounds like a basically reasonable idea, though I'm skeptical that it calls
> for changes to the base Ur/Web distribution.
>
> I probably should have been clearer about this before: I don't expect
> periodic tasks to work at all in CGI applications.  In fact, I'll go and
> make it a compile-time error now!  I also don't expect anyone to use CGI for
> anything serious, period.
>
> Does the picture get much simpler if you rule out CGI?  Does that remove
> some arguments for modifying Ur/Web itself?


By calling my arguments idealistic I mean that I agree that 1 second
delay is not a practical problem for my downloader example, but I
believe that there may be tasks with more strict requirements. So I'm
against making periodic polling an 'official guideline' of handling
callbacks. Also, there is other reason: 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..

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

uw_context* uw_clone(uw_context* ctx);

the rules may be following: uw_clone takes existing context and
creates a new one, with the refererence to same application and
loggers, and with it's own database connection and with no transaction
running (so it is safe to call uw_begin\uw_commit on it). Actually,
there should also be a way to obtain the uniq id, but it is not hard
as well.

This single method looks generic enough and should solve the problem
(however, I have some thought about proper termintation of threads,
but they are not that important for now). What do you think about
allowing FFI libs to create new contexts this way?

Regards,
Sergey