During week 7 I've focused on developing a plugin that uses the new
plugin api event handling to test usage complexity and functionality.
I choose to rewrite the fastcgi plugin for the new plugin api.
This lead to some minor changes in the api to allow more powerful
resource management.
Since the fastcgi plugin is not yet completed I have a lot of `Fixup`
commits so I've not pushed any code related to these changes yet.
When I've cleaned up my timeline I will push all changes to github.
# API changes - Cleanup operations
Before the changes were applied, resources could only be released by
using a destructor callback set in the content was added to the response
body.
The most obvious usage of this is to free malloc'd buffers by using
`free()` as destructor.
int mk_body_send(struct session_request *sr,
void *data,
size_t nbytes,
void (*destructor)(void *data));
The previous fastcgi implementation uses reference-counted memory chunks
to keep output until delivered to the client.
Each chunk can contain multiple pieces of output that may belong to
different requests (when multiplexing).
I wanted to continue using this in the new plugin, but the destructor
callback proved hard to adopt for this without heavy pointer arithmetic
and special values.
So as a solution to this I added the ability to queue cleanup
operations, both for generic pointers and for files.
int mk_body_cleanup(struct session_request *sr,
void *ptr,
void (*funcp)(void *ptr));
int mk_body_file_cleanup(struct session_request *sr,
int fd,
int (*funcp)(int fd));
These are added on the delivery queue and executed when all data of all
entries up to the cleanup entry has been marked used.
Since cleanup is already supported for by the `mk_queue` implementation
it is a very simple change with great implication.
To use reference counted memory I now `retain` the content, add the
content to the body using `mk_body_send()` and then also add a `release`
cleanup call.
These changes also allow for any resource cleanup after a request is
completed (or when a filter has consumed the content).
# Fastcgi plugin synergy features
Due to how filters work, the fastcgi will benefit from the features of
all filters developed so far.
Fastcgi responses will therefore be chunked without any changes and
compressed using the following `Plugins` entry.
[Location]
Path /fcgi-bin/
Plugins deflate fastcgi
# Next week
Next week I will complete the fastcgi plugin and document all three
example plugins (static, deflate and fastcgi).
These three plugins will then serve as documentation for plugin api use
and patterns.
I am also planning to implement a `range` plugin for supporting HTTP
ranges on any content.
It would work similar to `deflate`, adding headers and a filter in the
request handler.
[Blog](https://lotrax.org/gsoc/gsoc-2013-status-future-protocols-week-7.html)
[Code](https://github.com/ksonny/monkey/tree/plugin_next)
--
Sonny Karlsson
_______________________________________________
Monkey mailing list
[email protected]
http://lists.monkey-project.com/listinfo/monkey
