[gambit-list] Some high level questions about open-tcp-client

Rob Kellock sales at creditscore.co.nz
Mon Jul 7 22:15:29 EDT 2014

Thanks Jeff,

Still gotta ask though, if I use a loadable module, will it block? I had 
a bad experience a number of years ago where I developed an application 
using Zope, a Python web server, calling out to this same C database 
socket library using a Python-C bridge called a *.pyd  Everything was 
going swimmingly until I put it into production and discovered that the 
Python-C bridge blocked Zope. Problem there was the Python GIL, there 
was no work around and the project had to be cancelled. Ever since then 
I've been very wary of threads.

Here too in Gambit aren't the threads green threads rather than OS 
threads? I don't understand continuations yet, so I'm unsure whether 
they are being used somehow in Gambit to keep the green threads from 
being blocked, but I am concerned that as soon as the threads try to 
communicate with the outside world, Gambit will block.

The TCP server, uses htonl, htons and ntohl, ntohs on the C struct, so I 
guess that covers the endianess etc you mentioned.



On 8/07/2014 10:24 a.m., Jeff Read wrote:
> On Jul 7, 2014 5:54 PM, "Rob Kellock" <sales at creditscore.co.nz 
> <mailto:sales at creditscore.co.nz>> wrote:
> >
> > Hi,
> >
> > Quite some time ago I managed to successfully interface with a C library
> > using FFI.  Now I'm having another go, but this time I want to connect
> > to it using native Scheme code.  The C library is the interface to a
> > select based TCP socket server, so I figure I should be able to connect
> > to it directly using open-tcp-client and forgo the whole FFI thing.
> >
> > The way the C library works is that a C struct is sent to the receiving
> > socket first so that it knows the length of the message buffer that will
> > follow and some other information specific to the socket server's
> > operation. This is immediately followed up by the message buffer which
> > is in binary format.
> >
> > So far... I think I've managed to work out that I should be using
> > u8vector data structure for both the C struct and the message buffer,
> > although I don't yet understand what kind of encoding is going on in
> > there. That will come after I've looked at some examples.
> >
> > My plan is to extend the existing web-server.scm example to produce a
> > web app that talks to it's relational database using native Scheme. I'm
> > going down this route because I want to extend web-server.scm using the
> > GSI.  If I use the FFI I'm restricted to the GSC which prevents the
> > whole interactive development scenario I want where I can keep the
> > browser running, the database running and just stop and start the GSI as
> > I hack code.
> >
> > What I want to know first though is if I use open-tcp-client inside
> > Gambit's threads will the native Scheme calls out to the external socket
> > server block?  If they don't then am I on the right track to use 
> u8vector?
> >
> Yes, using u8vector is the way to go imho.
> I find it strange -- and a misfeature -- that the TCP server accepts a 
> C struct, because depending on what architecture the server is running 
> on and even what compiler was used to build it, the length, 
> endianness, and padding of the fields in the struct can vary. So you 
> will have to take those into account when packing a u8vector full of 
> bytes to send to this server.
> And you can certainly use FFI functions from within gsi. Simply 
> compile just the FFI wrapper with gsc into a loadable module, then 
> load it with LOAD into gsi while you develop the upper level bits in 
> Scheme.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20140708/12824770/attachment.htm>

More information about the Gambit-list mailing list