[Ur] callbacks from C FFI (again)

Adam Chlipala adamc at csail.mit.edu
Sun Dec 29 13:09:56 EST 2013


On 12/29/2013 12:55 PM, Sergey Mironov wrote:
> 2013/12/21 Adam Chlipala<adamc at csail.mit.edu>:
>    
>> 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?



More information about the Ur mailing list