Re: GNAT and Tasklets

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:m6t1f1$5th$1@dont-email.me...
> On 2014-12-17 23:08, Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> 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.