- 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.
I would be interested in seeing a sample to that.
On Thu, Mar 19, 2009 at 3:00 PM, Marc Feeley feeley@iro.umontreal.ca wrote: I
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.
- 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.
- You can start a database server and communicate with it using
sockets.
- 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
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list