From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: What exactly is the licensing situation with GNAT? Date: Fri, 21 Nov 2014 16:12:15 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87389olqie.fsf@ixod.org> <19fa65d4-72c9-44ab-b44b-4ea0929c18f2@googlegroups.com> <25731193-c0b5-4ab7-87ff-ba8c6a42cdbd@googlegroups.com> <1se4bvo6gaqft.16cfjaiketlz0$.dlg@40tude.net> <13efsbp4ynti1.1qsb6buqa4a60.dlg@40tude.net> <1lxkqa97hflr0.1c0bm39tzl8ty$.dlg@40tude.net> <2k62zlcocx1l$.1cg687ltl85l9.dlg@40tude.net> <1u2gy6fhz9fpr$.vzj1o4ueae0g$.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1416607936 9768 24.196.82.226 (21 Nov 2014 22:12:16 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 21 Nov 2014 22:12:16 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.giganews.com comp.lang.ada:190924 Date: 2014-11-21T16:12:15-06:00 List-Id: "Dmitry A. Kazakov" 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.