Re: What exactly is the licensing situation with GNAT?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1u2gy6fhz9fpr$.vzj1o4ueae0g$.dlg@40tude.net...
> On Thu, 20 Nov 2014 15:23:14 -0600, Randy Brukardt wrote:
>
>> But you seem to have missed my point: in Janus/Ada, task blocking is
>> irrelevant. If a task blocks in an Ada sense, that just causes the task
>> supervisor to select a different task to run.
>
> I see. But how a Janus/Ada task could use blocking sockets then?

A combination of two things: smart polling (don't try to read anything if 
not ready) and setting an imediate timeout for reading (so you get whatever 
is read and nothing more). Essentially, we're using blocking sockets in a 
non-blocking manner. But setting the sockets to non-blocking initially 
caused a lot of additional overhead.

>> (4) A socket write blocks when it reports that it can accept data. This
>> should be rare (it would mainly occur if some buffering issue came up, 
>> and
>> we write relatively small amounts of data at a time to reduce the 
>> likelyhood
>> of overfilling buffers).
>
> A non-blocking socket should accept as much data it can and then
> immediately return.

Maybe, but that's not how it worked when I investigated. Of course, that was 
years ago (and on W2K), so it could have changed.

...
>> (After all, Claw polls Windows for notifications, so the effect is
>> essentially the same at the low level.) I had to assume that there was 
>> some
>> massive expense associated with the non-blocking sockets notifications
>> inside of Windows -- profiling showed that the CPU load wasn't in the Ada
>> code (not even in the interface code). I gave up at that point and 
>> switched
>> back to basic polling with blocking sockets.
>
> If notification was done per Windows messages mechanism then certainly 
> yes,
> this is a heavy burden. However usually all notification is just pulsing 
> an
> event associated with the socket. Single pulse event is shared by all
> sockets to wake up a thread that then restarts polling sockets status. I
> don't know how much overhead is in signaling an event. It should not be
> much.

Event? Windows doesn't have anything like that (the only events I know about 
are messages). Windows does have some sort of Mutex (forget what they're 
called), but I've never paid any attention to them because they are useless 
within the Janus/Ada universe. That's because the whole point of a mutex is 
to block a thread until something sets the mutex, but that would block the 
entire Janus/Ada program. I suppose you could poll one, but you can poll the 
socket (or whatever) directly so there's no benefit to having a mutex.

I suppose one could use some assembler to set up a thread specifically for 
these notifications (that's what we had to do for DNS, not something I'd 
recommend for the faint-of-heart :-), but I don't see any real advantage to 
it.

>> As I said, the situation would be very different for GNAT, where each 
>> worker
>> task is a different thread. That would most likely block each worker task
>> early for a polling implementation, so hardly anything would be counted. 
>> In
>> which case your concern would have been justified. But I didn't run this
>> test with GNAT.
>
> And it would be an awful kind of server design anyway...

Well, it's the way my servers are designed, and it works great (at least for 
typical Internet protocols ike HTTP, SMTP, FTP, etc.). It probably would be 
too slow if one needed much faster latencies (1 millisecond rather than 100 
milliseconds), but I don't need that, and I see no reason to overdesign 
things.

                                               Randy.