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

Jeff Read bitwize at gmail.com
Mon Jul 7 22:23:11 EDT 2014


On Mon, Jul 7, 2014 at 10:15 PM, Rob Kellock <sales at creditscore.co.nz> wrote:
> 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.

So far as I know, synchronous I/O with the server will block Gambit
because yes -- Gambit uses green threads and switching between them is
done inside the select loop. If the library provides the capability to
do asynchronous I/O with callbacks, then you can get around the
blocking that way.

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

Not really. Doesn't specify the padding. Also, there's the fact that
an 'int' can be of different sizes depending on CPU architecture *and
compiler*.

The *right* way to specify wire protocols and file formats with
aggregate blocks of data is to explicitly specify the format down to
the byte level, including endianness for multi-byte integer and
floating-point values.

That people still do *not* do this is quite alarming.



More information about the Gambit-list mailing list