[gambit-list] Web applications in Gambit

Marc Feeley feeley at iro.umontreal.ca
Thu Mar 19 18:00:05 EDT 2009


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




More information about the Gambit-list mailing list