Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #100619

Re: (Execution) Termination bit, Alternation bit.

Show all headers | View raw

On Sat, 19 Dec 2015 18:56:17 +0100, "Skybuck Flying"
<skybuck2000@hotmail.com> declaimed the following:

>Hello,
>
>I'd like to see instruction execution enhanced with the following two ideas:
>
>1. A termination bit, and a terminator pointer.
>2. A alternation bit, and a alternate pointer.
>
>The purpose of these bits is as follows:
>
>Before a processor/core executes an instruction both bits are examined.
>
>1. If the termination bit is set the instruction is not executed and instead 
>the processor sets the instruction pointer to the termination pointer.
>2. If the alternation bit is set the instruction is not executed and instead 
>the processor sets the instruction pointer to the alternation pointer.
>
>The idea behind this is support multi threading/parallelism better.
>
	Don't see it here... You've just enabled leaving lots of corrupted data
structures in the system... (Imagine your "termination" branch is taken
after a call that allocated a 500MB block of memory, but before the call
that returns that memory to the system).

	This is why all well-designed multi-thread (and even multi-process --
though processes are typically an OS level entity which can be killed and
all resources reclaimed as they are not in a shared memory space) tend to
rely upon known points of communication and signalling.

	One of the bedrocks of software engineering has been the concepts of
cohesion and coupling. High cohesion: a block (function, etc.) of code is
focused upon a task, not containing bits of stuff involving multiple
unrelated work. Low coupling: blocks are independent of other blocks, with
only a few known points of information transfer -- few, if any,
side-effects, no mysterious globals... They should be black-boxes whose
inner content can be changed without affecting any other code.

	Your externally inflicted bits and jumps violate all of these as they
require outside code to know what the inside looks like to make safe use of
them.

	The "bits" are not the problem, but the uncontrolled/asynchronous
transfer of control is a big problem! The "bits" themselves are nothing
more than a recreation of VMS Event Flags (or even AmigaOS signal bits) --
they can be asynchronously set; but to act upon them requires a synchronous
operation*... That is, some sort of read operation in a loop or at other
known code points at which the code itself can cleanly change its path of
execution.


* I'm ignoring ASTs -- software interrupts -- since they don't cause a
transfer of control of the thread itself; they activate, run quickly, and
return to the point of activation.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

(Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-19 18:56 +0100
  Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-19 21:27 -0500
  Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-20 14:44 +1100
  Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-20 12:25 +0100
    Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-20 11:21 -0500
    Re: (Execution) Termination bit, Alternation bit. eryk sun <eryksun@gmail.com> - 2015-12-20 22:04 -0600
    Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-21 13:40 +0100
      Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-21 12:57 -0500
        Re: (Execution) Termination bit, Alternation bit. Grant Edwards <invalid@invalid.invalid> - 2015-12-21 19:32 +0000
          Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:25 +0100
            Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2015-12-30 00:22 +1100
              Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 22:43 +0100
                Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-30 11:00 +1100
                Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2016-01-03 02:18 +0100
                Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2016-01-03 19:44 +1100
                Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2016-01-08 12:59 +0100
          Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:42 +0100
      Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-22 16:46 +0100
        Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-23 02:56 +1100
          Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:23 +0100
  Re: (Execution) Termination bit, Alternation bit. Rustom Mody <rustompmody@gmail.com> - 2015-12-29 20:07 -0800
    Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2015-12-30 23:56 +1100
      Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-30 12:19 -0500

csiph-web