Previously failures could lead to no resources in the pool, and
waiters which will never get a resource. Retrying here fixes that
issue, although maybe another approach is needed that keeps track of
new resources being created, as that'll allow keeping track of this
when destroying resource pools.
Which call put-bytevector for performing output. When used in
combination with an unbuffered port, this should be safer than using
the normal Guile procedures, as I think it'll avoid writing to the
buffers, while still avoiding single character at a time output.
More research is needed though in to how to output to stdout/stderr
when using fibers with a parallelism greater than 1.
Rather than raising an exception when there's a body provided, use the
body as normal to inform the headers, as this is useful, and just
don't write the body to the client.
This was motivated by trying to allow for completely cleaning up
resource pools, which involved removing their use of fiberize which
currently has no destroy mechanism.
As part of this, there's a new parallelism limiter mechanism using
resource pools rather than fibers, and also a fixed size resource
pool.
The tests now drain? and destroy the resource pools to check cleaning
up.
Allow the thread pool to vary in size by basing it on a resource pool
of fixed size thread pools, which are similar to the previous thread
pool implementation.
Fixed size thread pools don't require fibers, but thread pools now
do. Some procedures work with either thread pool implementation.
Add the ability to specify the max number of waiters for a resource
pool, this provides a more efficient way of avoiding waiters for a
resource pool continually rising.
This commit also improves the destroy behaviour.
This turned out not to be useful, since I wanted to handle exceptions
happening in the exception handler, so it didn't really help in the
end to allow customising it.
