Path: Xl.tags.giganews.com!local-2.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 02 May 2024 03:09:37 +0000 Subject: Re: Threads across programming languages Newsgroups: comp.lang.c++,comp.lang.c References: From: Ross Finlayson Date: Wed, 1 May 2024 20:09:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Lines: 269 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-bZesrcI0ULbO3i21haMlE3X5fh+BfBNgD/G0zo6ES4q34ipVpUWIZeOgYJW/lwP6P5T0MuSSqAmrhV5!7hqKixUOnbfTuUU/iqRfstQ10zPCvlbedVEekrfK7DMFmeAj9pHlLZqG6nGP7qhKpPgGTU8YYdxO X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Bytes: 15272 >> >> Then of course obligatory about C++, or, C/C++, >> it's about OS threads and, "guarantees". >> >> >> Here my approach is "re-routines". "Re-routines: >> it's a co-routine, though instead of suspending >> it just quits, and instead of switching it just >> builds its own monad for the recusion, and >> instead of having callbacks, it's always callbacks, >> and instead of having futures everywhere, >> it's futures everywhere. Try, try again." >> >> In the process model in the runtime though, >> it's mostly about what services the bus DMA. >> "Systems", programming. >> >> Boxes is nodes, .... >> Re-Routines So, the idea of the re-routine, is a sort of co-routine. That is, it fits the definition of being a co-routine, though as with that when its asynchronous filling of the memo of its operation is unfulfilled, it quits by throwing an exception, then is as expected to to called again, when its filling of the memo is fulfilled, thus that it returns. The idea is that re-routines are originated in an origination or initiation context, an original re-routine, then it invokes either other re-routines, or plain code with an adaptor to keep the routine going, side routines, then as with regards to exit routines, and return routines. It's sort of in the language of the comedy routine, yet is a paradigm in the parallel and concurrent process model of the cooperating multithreading, and the co-routine. It's a model of cooperative multithreading, with the goal of being guaranteed by the syntax of the language, and little discipline. The syntax and language of the re-routine is a subset of the ordinary syntax and language of the runtime. The basic expectation is that a ready result is a "usable" object or value, and behaves entirely ordinarily, while an unready result, is an "un-usable" object or value, that can be assigned and lvalue in the usual definition, or added to a collection, yet when de-referenced or accessed, or via inspection, is determined "un-usable", with a defined behavior, to throw an exception, or throwable, and with the idea that it's not even necessarily a declared or checked exception. In languages with exception handling, exceptions un-wind the stack context of their invocation until, as from they were thrown ("throw", "raise"), they are caught ("catch", "rescue"). It's figured that copying and moving around an "un-usable" object is ordinary, then that any sort access its object or value throws, and that any re-routine, has it so that any object or value it results returning, is only "usable" objects or values, or collections of usable objects or values. It's figured that collections or any other holders, are OK with un-usable objects, only that effectively de-referencing the object or value that is un-usable, throws an un-usable exception. So, in languages like Java and C#, which run in a runtime that interprets the objects and values, and where there's a reserved value assignable to any object or value type, un-ready results are just "null". In languages like C++, where there are no un-usable objects of this type, and where the semantics of assignment may be complicated, and where de-referenceing "null" causes a segfault or machine error instead of an exception that can be caught, re-routines return the type of a value-holder for the object or value, called a "future", then that any accesses to the object or value through the holder, then can "throw" if un-ready or return the value or object its value when ready. The "future" is a library type and mostly common in all languages, and already has these loose semantics, then that it's un-necessary in Java or C# because why bother cluttering the signature, if these or re-routines, though maybe it's a good idea anyways, whether catching "NullPointerExceptions" is any more involved that catching "FutureExceptions". The re-routine thusly, meets only a Java declaration, or as of a pure abstract C++ method, its method signature is any usual signature that expect usable arguments, and throws any exception specification, and returns usable return values, though with never throwing the exceptions, that indicate the unfulfilled, that is the pending fulfilled, "un-usable exceptions". Then, the result of a re-routine, is its usable return value, or, what usable exceptions, are from the normal flow-of-control in the normal syntax of the language, and the behavior is defined thusly exactly the same. The originator of a re-routine, gets called-back with the result, either the return value or an exception that it can itself re-throw or swallow or translate, re-routines that call re-routines just get the return values or have thrown the exceptions, re-routines that call side-routines, must have that the side-routine calls-back, what is otherwise an "exit" routine, from the re-routine. (As a matter of style, then indicating that re-routines are re-routines, there's one original re-routine, it calls re-routines or side-routines, and if it calls side-routines, then it's figured that it's an exit routine, yet not in the usual sense that "exit" means to "exit" the runtime, just that it expects the side-routine to invoke a call-back it provides, to re-enter the re-routine.) The context of the origination, then, is that a thread, is expected to pick up these re-routines as a task, from a queue or provider, supplier, of the tasks. The idea is that each re-routine is a class instance, i.e. it's an object as defined by a class an instance of the class the object, and the instance, has associated its memo, from the origin. In languages like Java, there's a "ThreadLocal", and in C++ there's a storage specification, "thread_local". When the task supplier is invoked, it's in the calling context, of the thread, a worker or task worker. The body of "get()", sets the values of otherwise the static or global ThreadLocal or thread_local, of the task's memo, then that as long as the thread is working on the task, the re-routine's instance access to the memo, is specific to original re-routine, and the re-routines it calls, all in the context, of the same thread. It's figured that any state of the re-routine, is specific to the instance of the re-routine, and the thread, and its scope, its thread locals, and globals. The re-routine instance may be of a bunch of re-routine instances so their memo is the thread local memo. The memo's nowhere part of the method signatures, of the re-routines. Callers calling Re-Routines This is the origination of a re-routine: it's basically en exit-routine from the caller, to the submission to the task queue of the re-routine originator, with calling back the caller. Re-Routines calling Re-Routines Re-routines, basically have an interceptor or layer, an aspect, before invoking the body of the routine. A: step -1) if the usable return value or usable exception is already in the memo, return it (throw it respectively) B: step 0) if any of the arguments, or any of the held values, are un-usable, then throw an un-usable exception C: step 1) invoke the body of the re-routine, and C1: if calling a side-routine, put an un-usable return value in the memo, and invoke the side-routine, and return an un-usable object C2: if calling a re-routine, it's these same semantics, the re-routines keep the same semantics going C9: when eventually returning or throwing a usable exception, put it in the memo Re-Routines calling Side-Routines It's figured that re-routines calling side-routines, makes the re-routine an exit-routine, then that when it's called back by the side-routine, is to initiate the exit-routine as an exit-re-enter-routine. The idea is that the exit routine provides a callback, and invokes whatever function in whatever thread context, and the specification of the callback, is that the original initiator or originator supplier, has a way to re-submit the task, of the exit-routine. Then there isn't really a strong compile time guarantee, that side-routines call-back their exit-re-enter-routine. It's figured that side-routines must accept a signature of the call-back, and it's figured they do, thus that the side-routines, call back with the return value or exception, and, the callback body puts the return value or exception on the memo, translated as necessary to a usable object or a usable exception, or a translation of an unusable object or exception as a usable exceptiopn, re-submits what was the exit-routine, that as the exit-re-enter-routine, now completes, about how to re-enter the routine, that the re-routine is re-entrant. Re-Routines are Re-Entrant The idea here is that the routine that's unready, when it's fulfilled, it can either call all over again the entire original re-routine, or, it ========== REMAINDER OF ARTICLE TRUNCATED ==========