Improved Cocoa bridge; fixed some I/O bugs

The Cocoa bridge now uses runtime introspection to discover methods defined on classes. While the current implementation is far from perfect, it saves me from the pain of declaring methods by hand, and it works well enough to run a minimal web browser demo:

• Source code
• Screenshot

The Cocoa bridge is far from complete. It needs to support Objective C exceptions, autorelease pools, subclassing, messages that return structs, and various other odds and ends. Subclassing is the hardest one, since it requires callbacks to be implemented first. However, 100% coverage of the Cocoa feature set is not a goal, since I'll only be using this binding as a backend for the Factor UI, not directly for application development (but then, who knows).
Over the last week or so the factorcode.org server went through some rough times. I was running the HTTP server and IRC bot in the same Factor instance, and it started to crash on a regular basis. Turns out there were two race conditions in the I/O code:

• If one thread posted a write request to an I/O port and another thread closed the port before the write request was serviced, the port would actually be closed before the former request was completed, because incredibly enough, I implemented the callback queue as a stack. Making it a real queue fixed the problem


• The second problem was trickier. If one thread closed a stream with pending output, and another thread wrote more output to the stream before the originally pending output was complete, the same problem would occur, in that the port would be closed before all I/O was complete. This time, the fix was not FIFO -vs- LIFO, but simply marking a port as closed before pending output is flushed; so once a close operation is initiated, no more output other than the final flush can begin.

Another problem was a scalability issue. The file responder used Chris Double's cont-responder framework, which is very nice and clean. It had one problem, however, in that it would queue up the entire response in a string before sending it to the client -- this was a problem if several people begin downloading a large file at the same time! This is also now fixed.
I'm guessing the factorcode.org server is the highest-volume deployment of the Factor HTTP server to date, so it has uncovered some bugs I'd never notice during local testing. Hopefully, there won't be too many more.