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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT and Tasklets Date: Wed, 17 Dec 2014 17:58:00 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1418860681 8897 24.196.82.226 (17 Dec 2014 23:58:01 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 17 Dec 2014 23:58:01 +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: news.eternal-september.org comp.lang.ada:24087 Date: 2014-12-17T17:58:00-06:00 List-Id: "Björn Lundin" wrote in message news:m6t1f1$5th$1@dont-email.me... > On 2014-12-17 23:08, Randy Brukardt wrote: >> "Niklas Holsti" wrote in message >>> As I remember, the user-level thread solution in GNAT had the drawback >>> that if one thread blocked on an OS call, the whole program was blocked. >> >> True, but that's not a real problem in most software (that has to respond >> in >> human timescales - if you need microsecond response times, forget >> Janus/Ada!). > > That kind of rules out a common pattern we have in communication > processes. Certainly not: my web and mail servers do plenty of communication! > Usually we set up a socket, globally, in a package body. > > One task does a blocking select() - thus hanging on it - for say 5-30 s. Here's the problem, you're thinking at much too low of a level. The Claw/NC sockets libraries abstract sockets comminucation into an I/O model (no such thing as "select"!). And the implementation can avoid actual blocking (even though at the call level you will see what appears to be blocking). Get (My_Socket, Timeout => 30.0, Item => Buffer, Last => Last); This will appear to block for 30 seconds, but it surely doesn't have to be *implemented* that way. For servers, there is a server object. "Greet" returns an open socket for a connection. Again, this appears blocking, but doesn't have to be implemented that way. [Truth-in-advertising notice: The Claw libraries actually do block. I wrote an abstraction extension on top of them that don't block -- but those use the exact same subprogram profiles, so there's no operational difference.] I don't see any sense to the other tasks that you have (I realize I don't understand the precise problem that you are trying to solve). But it all seems WAY too low-level to me; the reason for using such a pattern is that you need high speed responsiveness (far faster than human speeds) -- otherwise sticking with a simple I/O model is much easier to understand for maintenance. On top of which, using the same (Ada) object from two different tasks without synchronization is an invalid use of shared variables. Such a program is technically erroneous, and as such, it could do anything at all. So I'm dubious that your pattern even works on other compilers (regardless of the blocking issue). It's unfortunate that Ada doesn't have any static checking for such things, because it's all too easy to write something that works today but won't work in the future. Randy.