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