On 12/29/2013 12:55 PM, Sergey Mironov wrote:
2013/12/21 Adam Chlipala<[email protected]>:
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.
The reason (probably a bit too idealistic) is to avoid hardcoded
latencies, even as small as one second.
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.
I need a function which may be called from FFI-code to enqueue the
url. This function should be thread-safe and uw_context-free.
Basically it's signature may be as simple as 'void (*)(const char *
url)`. The question is how to implement it. I don't see a way to
combine it with periodic tasks without aggressive polling from the
task's side, that is why I'm still suggesting to keep a separate
thread (or a fixed number of threads) to handle the URL queue, just
like http.c does to handle incoming requests. But please point me to
another solution if it exists.
Sounds like a basically reasonable idea, though I'm skeptical that it
calls for changes to the base Ur/Web distribution.
Also, I thought about the behavior of periodic tasks in cgi-mode.
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?
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
