[gambit-list] Web applications in Gambit

Pavel Dudrenov dudrenov at gmail.com
Thu Mar 19 18:10:39 EDT 2009


> 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.
>

I would be interested in seeing a sample to that.


On Thu, Mar 19, 2009 at 3:00 PM, Marc Feeley <feeley at 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.
>
> 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
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>



More information about the Gambit-list mailing list