On 19-Mar-09, at 4:37 PM, Andrew Whaley wrote:
I've made some good progress in the last couple of days by finding the ssax-sxml library and Francisco Ferreira's basic scgi interface. Putting these together with a multithreaded dispatcher, I now have gambit serving complex SXML web pages in around 50ms which is about 20 times faster than SISCWeb with the same page.
Great! A factor of 20 should be noticeable!
I have an immediate problem in that the main thread which listens for incoming connections and then spawns handler threads for each page requests works fine if I run it in the REPL window but that then prevents REPL from doing anything else. If I try and spawn a separate thread for this listener so that I can carry on using REPL then the listener stops running unless I repeatedly press return in the REPL window !
That is strange, but it reminds me of a bug that has been fixed. Could you double check if Gambit v4.4.2 also has this problem? If it does, then that sounds like a real bug. If you could package up your sources and send them to me then I can try to find the cause.
I have enough working now to start on the continuations based web framework but pretty soon I'll need to try and interface with a backend database e.g. Oracle or MySQL.
There are a few (My)SQL bindings on the Gambit Dumping Grounds. Perhaps one of them will suit your immediate needs.
The obvious way to do this will be to use the relevant C API for the database but I'm guessing that if I call into C then all the pseudo-threads in Gambit will stop until the C call returns - is this correct ? This would probably OK for a short call but would be disastrous for a long running call e.g. to a database that has a latency of at least 30ms and could be several seconds for some queries.
Yes this could be a problem. There are several approaches to solve the problem.
1) Some databases offer an asynchronous API. You can send your request, continue other processing, and be informed when the operation is done. I'm not sure if MySQL has this.
2) You can start a database server and communicate with it using sockets.
3) You can do like 2 but avoid the socket overhead by starting an in- process OS thread which handles database requests. Then you need to implement a simple bidirectional FIFO structure for the Scheme code to talk to this OS thread. You could even start several OS threads and load-balance your requests. If you are interested in this approach then let me know and I will write a sample.
Marc