<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Jeff,<br>
<br>
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.<br>
<br>
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.<br>
<br>
The TCP server, uses htonl, htons and ntohl, ntohs on the C struct,
so I guess that covers the endianess etc you mentioned.<br>
<br>
Cheers,<br>
<br>
Rob.<br>
<br>
<div class="moz-cite-prefix">On 8/07/2014 10:24 a.m., Jeff Read
wrote:<br>
</div>
<blockquote
cite="mid:CAL6nvpV2GYMkW6MRU3Q83pZjyaFYFxG6kqhpi6wuLp5+P5VgYQ@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On Jul 7, 2014 5:54 PM, "Rob Kellock" <<a
moz-do-not-send="true" href="mailto:sales@creditscore.co.nz">sales@creditscore.co.nz</a>>
wrote:<br>
><br>
> Hi,<br>
><br>
> Quite some time ago I managed to successfully interface
with a C library<br>
> using FFI. Now I'm having another go, but this time I want
to connect<br>
> to it using native Scheme code. The C library is the
interface to a<br>
> select based TCP socket server, so I figure I should be
able to connect<br>
> to it directly using open-tcp-client and forgo the whole
FFI thing.<br>
><br>
> The way the C library works is that a C struct is sent to
the receiving<br>
> socket first so that it knows the length of the message
buffer that will<br>
> follow and some other information specific to the socket
server's<br>
> operation. This is immediately followed up by the message
buffer which<br>
> is in binary format.<br>
><br>
> So far... I think I've managed to work out that I should be
using<br>
> u8vector data structure for both the C struct and the
message buffer,<br>
> although I don't yet understand what kind of encoding is
going on in<br>
> there. That will come after I've looked at some examples.<br>
><br>
> My plan is to extend the existing web-server.scm example to
produce a<br>
> web app that talks to it's relational database using native
Scheme. I'm<br>
> going down this route because I want to extend
web-server.scm using the<br>
> GSI. If I use the FFI I'm restricted to the GSC which
prevents the<br>
> whole interactive development scenario I want where I can
keep the<br>
> browser running, the database running and just stop and
start the GSI as<br>
> I hack code.<br>
><br>
> What I want to know first though is if I use
open-tcp-client inside<br>
> Gambit's threads will the native Scheme calls out to the
external socket<br>
> server block? If they don't then am I on the right track
to use u8vector?<br>
></p>
<p dir="ltr">Yes, using u8vector is the way to go imho.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
</blockquote>
<br>
</body>
</html>