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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.194.20.233 with SMTP id q9mr1576872wje.1.1466411002233;
        Mon, 20 Jun 2016 01:23:22 -0700 (PDT)
X-Received: by 10.157.41.105 with SMTP id d96mr387150otb.19.1466411002069;
 Mon, 20 Jun 2016 01:23:22 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!goblin1!goblin.stu.neva.ru!w10no3823656lbo.0!news-out.google.com!di11ni6112lbb.1!nntp.google.com!w10no3823653lbo.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 20 Jun 2016 01:23:21 -0700 (PDT)
In-Reply-To: <nk3cn7$1gab$1@gioia.aioe.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=134.158.76.29;
 posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr
NNTP-Posting-Host: 134.158.76.29
References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com>
 <dsim6eF91ubU1@mid.individual.net> <nk19hh$o33$1@gioia.aioe.org>
 <d9d7f8f5-8b72-450b-8152-4b6116c6ce2c@googlegroups.com>
 <nk31ru$10pb$1@gioia.aioe.org>
 <5b542d7c-e10e-4e3a-b98a-2b538bec0670@googlegroups.com>
 <nk3cn7$1gab$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0353aa58-328a-4abb-8101-678a379265cc@googlegroups.com>
Subject: Re: RFC: Prototype for a user threading library in Ada
From: Hadrien Grasland <hadrien.grasland@gmail.com>
Injection-Date: Mon, 20 Jun 2016 08:23:22 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:30826
Date: 2016-06-20T01:23:21-07:00
List-Id: <comp.lang.ada>

Le samedi 18 juin 2016 13:53:13 UTC+2, Dmitry A. Kazakov a =C3=A9crit=C2=A0=
:
> On 2016-06-18 11:17, Hadrien Grasland wrote:
>=20
> > But nonblocking IO is something I want to study more during the
> > evolution of this library, as I think it is something which stresses th=
e
> > limits of the event model I propose. Single-shot events are a good fit
> > when a clear notion of task completion exists, but they are less
> > suitable when dealing with continuous processes such as streaming IO.
>=20
> You could use a pulse event instead. The event is reset when all waiting=
=20
> tasks are released. It is not difficult to implement with protected=20
> objects using entry count attribute.

I am not very keen on this option because if is incompatible with state pol=
ling, which is useful for all kinds of non-waiting scenarios including comp=
onent testing ("what is the state of my event after performing this operati=
on?").

=20
> > I do not want to go in the direction of reusable events, as the
> > amount  of ways these can go wrong is all but infinite, however there h=
as to be
> a better synchronization primitive for this kind of progressive evolution=
.
>=20
> One solution is to have more states than Reset/Signaled. An event can=20
> traverse a larger set of states being a small state machine. As well as=
=20
> transitions may be initiated not only explicitly but also through=20
> scheduling events, e.g. task release in case of the pulse event.

Would you mean something like, for example, a discrete or floating-point pr=
ogress counter that can be programmed to fire an event when going above any=
 arbitrary level of progress?

That could be a very interesting avenue to explore indeed!