onExit() is similar to the onLoad() callback. onExit() is called on each
module just before the process exits. This can be used to check state in
unit tests, but not to perform I/O. The process will forcibly exit as soon
as all of the onExit callbacks are made.
This is sloppy: after each ObjectWrap allocation the user needs to
call ObjectWrap::InformV8ofAllocation(). In addition each class deriving
from ObjectWrap needs to implement the virtual method size() which should
return the size of the derived class. If I was better at C++ I could
possibly make this less ugly. For now this is how it is.
Memory usage looks much better after this commit.
The LowLevelServer is a direct interface to the parser given people access
to things like partially received headers. This could be used to implement
an extremely optimized server which acts before parsing is complete.
Most people will be using node.http.Server which is still rather low-level
compared to other http interfaces, but does take care of some details for
you.
Connections were being garbage collected while they were still in progress
since the object would leave scope. This commit adds ObjectWrap::Attach()
and ObjectWrap::Detach() to tell v8 that an object is currently on the event
loop and will be needed in the future.
Other changes to oi_socket.c and net.cc are to fix bugs encountered while
running the HTTP server.
Here I massively change both the external and internal API of the TCP
sockets and servers.
This change introduces the concept of a protocol object like is found in
Twisted Python. I believe this allows for a much cleaner description of how
a socket behaves. What was once a single object "client" or "connection" is
now represented by two objects: a "connection" and a "protocol".
Well - I don't want to ramble too much because neither API is yet public or
documented. Look the diff of test/test-pingpong.js to see how things have
changed.
Also changed Init_net() to Socket::Initialize() and Server::Initialize().
Seems more object oriented, but I'm unsure how this will play when I want
load modules dynamically with dlopen(). I'll sit with it for a while and
see how it feels.
This might need to be changed in the future if ev is needed in thread pools
or extension libraries. However for now it makes sense to just use a single
loop.
