Commits

Trent Nelson committed 6de5ed5 Draft

Checkpoint.

  • Participants
  • Parent commits 948c578
  • Branches async

Comments (0)

Files changed (1)

File pep-async.txt

 comes up for discussion, these requirements are cited as reasons why
 a given proposal won't be feasible.
 
-threading.Thread() is a Dead End
---------------------------------
 However, The common trait of past proposals is that they focused on
 the wrong level of abstraction: threading.Thread().  Discussions always
 revolve around what can be done to automatically make threading.Thread
 instances run concurrently.
 
+threading.Thread() is a Dead End
+--------------------------------
 That line of thinking is a dead end.  In order for existing threading
 Thread() code to run concurrently, you'd need to replace the GIL with
 fine-grained locking, such that only one thread could access the GC
 stimulate ideas and further discussion.
 
 The essence of the idea is this: in addition to the main interpreter
-thread, an additional thread is created for each available CPU core[1].
+thread, an additional thread is created for each available CPU core.
 These threads idle/wait against a condition variable by default.  That
 is, when there's nothing to be done in parallel, they do nothing.
 
 all of the existing memory allocation, reference counting and garbage
 collection framework?
 
-The idea offered by this PEP is as follows: each parallel thread's
-environment is set up such that it thinks its using the normal global
-malloc/refcount facilities, when in fact it has a localized instance.
+The idea offered by this PEP is as follows: each parallel thread is
+set up such that it thinks its using the normal global malloc/refcnt
+facilities, when in fact it has a localized instance.
 
 All object allocation, deallocation, reference counting and garbage
 collection that takes place during concurrent CFrame_EvalEx execution
 Obviously, the longer the parallel threads are permitted to run
 without being paused the better, but legacy code that relies on GIL
 semantics (especially with extension codes) will still run without
-issue in the mean time, nor will any performance penalties be incurred
-for not using the new parallel primitives.
+issue in the mean time.
 
 Because we don't introduce any fine-grained locking primitives in
 order to achieve concurrency, no additional overhead is incurred by