NEWS

   1 # -*- mode: org; -*-
   2
   3 #+TITLE: 8sync NEWS
   4
   5 : Copyright (C) 2015-2016  Christopher Allan Webber
   6 :
   7 : Copying and distribution of this file, with or without modification, are
   8 : permitted in any medium without royalty provided the copyright notice
   9 : and this notice are preserved.
  10
  11 * 8sync 0.3
  12
  13 ** 8sync now targets Guile 2.2, Guile 2.0 dropped
  14
  15 In order to take advantage of Guile 2.2's suspendable ports facilities,
  16 Guile 2.0 support has been dropped from 8sync.  (The Guile 2.1.X series is
  17 the Guile 2.2 preview series.  A minimum of Guile 2.1.4 is required.)
  18
  19 While this may make 8sync slightly harder to install before major free
  20 software distributions catch up (Guix users should have no problem), there
  21 are major benefits to be found as well; networked code will be
  22 significantly easier to write.  For more information, read on.
  23
  24
  25 ** Suspendable ports overhaul
  26
  27 Previous 8sync networked code required hooking up a "port request" to the
  28 scheduler, which would assign a port listening on a read or write event
  29 with a callback.  By making use of Guile 2.2's new [[https://www.gnu.org/software/guile/docs/master/guile.html/Non_002dBlocking-I_002fO.html][suspendable ports]] code,
  30 network enabled code mostly is completely straightforward to write.  If a
  31 port is set to be nonblocking, attempting to read or write to a port that
  32 would normally block will automatically suspend to 8sync's scheduler.  When
  33 that port is discovered to be ready to read or write, the agenda will
  34 automatically resume the suspended code.  As such, writing nonblocking code
  35 looks almost exactly like writing blocking code in Guile... very little
  36 extra work needs to be done.
  37
  38 8sync's internal demos and subsystems have also been updated to this
  39 feature.
  40
  41 Not all ports will work with the new behavior, but most involving a file
  42 descriptor will, which is the vast majority of I/O facilities.  Hopefully
  43 over time the range of ports which are available to take advantage of this
  44 feature will grow.
  45
  46 ** Overhaul of the "8sync" and "8sync-*" macros / procedures
  47
  48 The previous 8sync macro was realized to be a flawed design, more or less
  49 emulating a synchronous call stack while providing the main feature of
  50 yielding.  Thus 8sync, and several related macros (8sync-run-at, 8sync-run,
  51 8sync-delay, 8sync-run-delay) have been removed, and 8sync-nowait has been
  52 renamed to 8sync.
  53
  54 This leads to the question, "what is the primary coordination mechanism in
  55 8sync between asynchronous processes?"  At least for now, this is the actor
  56 subystem.  (While 8sync core continues to not require the actor subsystem,
  57 for the reasons just described, many users will want to use it.)
  58
  59 ** Actor system overhaul
  60
  61 Given its increased role in 8sync, the actor system has also received
  62 several major updates:
  63
  64 *** send-message and friends deprecated in favor of <- and friends
  65
  66 send-message, send-message-wait, reply-message, and reply-message-wait have
  67 all been removed in favor of what was previously their aliases: <-, <-wait,
  68 <-reply, and <-reply-wait.  The semantics are the same.
  69
  70 *** Message body now "applied" to a procedure
  71
  72 Previously to access a message body's contents, you used message-ref,
  73 since a message body was merely a key-value property list.  There was
  74 a special purpose message handler to make accessing the contents of a
  75 message's body easier, with define-mhandler.  Now this is no more,
  76 since invoking a message handler will call the procedure more or less
  77 like so:
  78
  79 #+BEGIN_SRC scheme
  80 (apply this-message-handler actor message (message-body this-message))
  81 #+END_SRC
  82
  83 "Waiting" for a reply message continues to return the message as
  84 before, but to access its body, the message is likewise applied, using
  85 either "receive-message" or "call-with-message".
  86
  87 *** New %current-actor parameter
  88
  89 *** Default message handler now "inheritable"
  90
  91 The default message handler now looks at the actor slot of the actor
  92 and its predecessors, which must have #:allocation #:class or
  93 #:each-subclass.  The #:init-value of the actor slot is just an alist
  94 of (action-symbol . message-handler).  There is convenient sugar for
  95 defining this alist named "build-actions".  Use it!
  96
  97 If for some reason you want to control the way messages are handled
  98 in some way that is different than the general pattern, you may
  99 customize the message-handler slot of your actor.
 100
 101 ** New yield procedure
 102
 103 Allows asynchronously executing code to voluntarily yield to the scheduler.
 104
 105 ** New procedure: 8usleep
 106
 107 Like usleep, but asynchronous.
 108
 109 * 8sync 0.2
 110
 111 The primary update to this release is the inclusion of a new actor
 112 model subsystem.
 113
 114 * 8sync 0.1
 115
 116 This is the first release of 8sync.  Welcome to 8sync!
 117
 118 The following features are present already in this very first release:
 119
 120  - An asynchronous event loop
 121  - Delimited continuation support via the (8sync) command
 122  - IRC bot demo