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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Musings on RxAda Date: Wed, 21 Oct 2015 15:35:22 +0200 Organization: cbb software GmbH Message-ID: <1wvo1b25eaa4o$.1y03vu1to6vux$.dlg@40tude.net> References: <75f38e30-42ba-4e98-8f36-2218b5167209@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: TWQ9mg4k1m/sph/eQ+zHLA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:28011 Date: 2015-10-21T15:35:22+02:00 List-Id: On Wed, 21 Oct 2015 05:12:40 -0700 (PDT), Hadrien Grasland wrote: > Reading through my post again, I should 1/Apologize for the missing words > here and there and 2/Point out that my implementation of Observable is > mostly synchronous, because all the costly mapping work occurs within the > accept rendezvous. > > To make an asynchronous Observer would require quite a couple more tweaks, > allowing the Observer task to save its entry parameters and use them once > the computation is over. In particular, the output channel should be > passed by access, rather than by in out value. > > This does not, however, void my core point that Ada's accessibility rules > would end up getting in our way if we wanted to implement something like > ReactiveX for Ada. Not going to pretend understanding what are you talking about, but synchronous vs. asynchronous in the context of publisher / subscriber is determined by whether the publisher is blocked by subscriber(s) or not. >From that point of view using tasks or other synchronization mechanism in the non-blocking (and thus asynchronous, and thus marshaling) scenario is straight out wrong. See? If you block, it is not asynchronous. A proper design pattern for non-blocking (and thus non-delivery guaranteed) 1-n publisher / subscriber scenario is a blackboard or sets of queues on the subscriber's side. Neither require tasks, nor access types (no in the form that something gets allocated in a conventional memory pool). Yes, at some point you will need to defeat the type system. That is a job for stream attributes, "for address use", or a fake memory pool. Either would work. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de