[Ur] Some more questions:

[Adam Chlipala]

Marc Weber wrote:
>> CGI doesn't support channels, while FastCGI involves multiple threads in
>> a single process.  Pending channel sends are only stored in-memory and
>> would certainly be lost in a sudden crash.
>>      
> So its important to tell webservers to only start one instance.
>    

Right.

> I don't understand the scope of regions yet.
> quote (manual):
>
>    void *uw_malloc(uw_context, size_t);
>    [...] Thus, there is no uw free(), but you need to be careful not to keep ad-hoc C pointers to
>    this area of memory.
>
>    For performance and correctness reasons, it is usually preferable to use uw malloc() instead of malloc().
>    The former manipulates a local heap that can be kept allocated across page requests, while the latter
>    uses global data structures that may face contention during concurrent execution.
>
> 1)
> looking at urweb.h there is a uw_free(). So ist he documentation out of
> date here? Or is it an internal function?
>    

That function is for freeing a context.  (You'll notice that it doesn't 
take a second void* argument, like you would expect for the usual 
'free'.)  I'll update the manual to fix the confusing wording you point out.

> 2) "can be kept allocated across page requests"
> Can I tell urweb to keep or throw away the memory after a request
> completes?
>    

No.  Think of this more like programming with a garbage collector, where 
you don't need to think about "throwing away" memory.  The manual 
sentence about "kept allocated across page requests" is a performance 
tip, not something you need to think about directly, even to avoid 
"memory leaks."  It's a uniform _heap_ that "stays allocated," not any 
object you deal with directly in your code.

> When is such a region guaranteed to end so that the memory will be
> freed?

I think it's best to let the compiler infer the best region locations.  
In the worst case, everything you allocate lives until the end of the 
page request.  For most applications, this isn't very long.  You can 
always use regular 'malloc' if needed.

> Let's assume I used system("cat 200mb.file") and send this to the user
> using blob (less than optimal because its not streamed .. But I don't
> care for now) .. When would the buffer I allocated to keep the stdout
> data be freed again?
>
> Because there is no uw_realloc (?) is the way to go using realloc,
> malloc copying the data into a uw_malloc'ed buffer before returning?
>    

Part of the answer here is that I acknowledge that the current support 
for sending files is suboptimal in several ways.

For your example, with the present Ur/Web implementation, I would look 
up the length of the file and then use either 'uw_malloc' or 'malloc' to 
allocate exactly that many bytes.  In the first case, you don't have to 
worry about freeing, but the allocation could permanently increase the 
size of the heap for the current context.  (It would be easy to add some 
kind of periodic heap-shrinking functionality; it just isn't there 
now.)  If you use 'malloc', you need to be careful that the memory is 
'free'd along every possible program path, including early aborts 
because of transaction rollback.  Functions like 'uw_push_cleanup' and 
'uw_register_transactional' are important for that kind of compensation.

As you can see, it's simplest to use 'uw_malloc', and I recommend doing 
that, only switching if you encounter real performance problems.

> Would it make sense to allow registering a default handler which can
> serve all requests urweb didn't find a function for?
>    

Ur/Web applications already return 404 codes properly for such 
requests.  This means you can configure your web server/proxy to use its 
usual 404 page or anything else you like.