comp.lang.ada
 help / color / mirror / Atom feed
From: Darren New <dnew@san.rr.com>
Subject: Re: Dynamic dispatch again
Date: Mon, 08 Oct 2001 19:07:56 GMT
Date: 2001-10-08T19:07:56+00:00	[thread overview]
Message-ID: <3BC1F97E.6EA2F1E7@san.rr.com> (raw)
In-Reply-To: k8mw7.16010$IY3.11154702@news1.rdc1.sfba.home.com

tmoran@acm.org wrote:
> 
> >Because not all profiles will (for example) send a message as the first
> >thing they do.
>   Ah.  I thought the profile fixed the tasking structure.  But it sounds
> like the only required similarity in these tasks is that their spec
> (list of "entry"s) is the same.  All else is changeable, correct?

Yes, ideally. Naturally, some limitations will exist, like
initialization will always happen before finalization. But other than
that, the ability to wait on multiple possible events at each point in
the conversation is important to not rebuilding the whole queueing bit.

>   So as I understand it, you want to be able to do something like:
>    task type One is
>      entry a(i : in out integer);
>      entry b;
>    end task;
>    task type Two is
>      entry a(i : in out integer);
>      entry b;
>    end task;
>    ...
>    X : array() of tasks_one_or_two;
>    ...
>    select
>      X(i).b;
>    or
>      delay 1.0;
>    end select;
> Is that it?

Right. With the understanding that One is going to actually need an
actual thread runnign when it's not in an entry, and wierdness in the
middle (extra levels of indirection, extra tasks that just requeue, etc)
are quite acceptable.

Right now, my alternative is to package up every "entry" as an object of
a tagged type and build a bidirectional queue of such things. Ugly.
Especially since there will be bits of code in the dispatcher that do
things like "ask each profile if it's ready to quit, and if any refuse,
return that refusal, otherwise return ok." A real PITA to do if you have
to queue a bunch of questions, then receive a bunch of answers, then
compare the two lists, waiting for everyone to answer, etc. Been there,
done that (in C), real ugly. :-) I thought with such sophisticated
rendezvous built into Ada, it ought to be easier than that.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?



  reply	other threads:[~2001-10-08 19:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-06  1:08 Dynamic dispatch again Darren New
2001-10-06 17:52 ` tmoran
2001-10-08  1:13   ` Darren New
2001-10-08  4:23     ` tmoran
2001-10-08 16:26       ` Darren New
2001-10-08 18:21         ` tmoran
2001-10-08 19:07           ` Darren New [this message]
2001-10-09  0:25             ` tmoran
2001-10-09  0:40               ` Darren New
2001-10-09  1:29                 ` Larry Hazel
2001-10-09  4:10                 ` tmoran
2001-10-09 15:40                   ` Darren New
2001-10-09 17:58                     ` tmoran
2001-10-09 19:26                       ` Darren New
2001-10-09 19:42                         ` tmoran
2001-10-09 20:23                           ` Darren New
2001-10-09 22:37                         ` tmoran
2001-10-10 18:17                           ` Darren New
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox