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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Mon, 20 Jun 2016 11:22:44 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> <5b542d7c-e10e-4e3a-b98a-2b538bec0670@googlegroups.com> <0353aa58-328a-4abb-8101-678a379265cc@googlegroups.com> NNTP-Posting-Host: vFKDMXWEWKqnQQwESBoFfw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30832 Date: 2016-06-20T11:22:44+02:00 List-Id: On 20/06/2016 10:23, Hadrien Grasland wrote: > Le samedi 18 juin 2016 13:53:13 UTC+2, Dmitry A. Kazakov a écrit : >> On 2016-06-18 11:17, Hadrien Grasland wrote: >> >>> But nonblocking IO is something I want to study more during the >>> evolution of this library, as I think it is something which stresses the >>> 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. >> >> You could use a pulse event instead. The event is reset when all waiting >> tasks are released. It is not difficult to implement with protected >> objects using entry count attribute. > > I am not very keen on this option because if is incompatible with > state polling, which is useful for all kinds of non-waiting scenarios > including component testing ("what is the state of my event after > performing this operation?"). If you know the tasks awaiting a pulse event you could make it compatible again by polling for event + task states. But since the environment is not really concurrent there is nothing to worry about. You cannot have a race condition within just one task. >>> 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 has to be >> a better synchronization primitive for this kind of progressive evolution.. >> >> One solution is to have more states than Reset/Signaled. An event can >> traverse a larger set of states being a small state machine. As well as >> transitions may be initiated not only explicitly but also through >> scheduling events, e.g. task release in case of the pulse event. > > Would you mean something like, for example, a discrete or > floating-point progress counter that can be programmed to fire an event > when going above any arbitrary level of progress? That too. But generally for a client a possibility to wait for any of the states or for any disjunction of states. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de