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.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
