Kyle R. Burton on 31 Jul 2007 15:30:37 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[philly-lambda] Receive, the Mailbox and the Save Queue

  • From: "Kyle R. Burton" <kyle.burton@gmail.com>
  • To: philly-lambda@googlegroups.com
  • Subject: [philly-lambda] Receive, the Mailbox and the Save Queue
  • Date: Tue, 31 Jul 2007 11:30:23 -0400
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=h17/VNQo2xy5LTnY/q3d3/BBrTfClEvb3T+1Ae6AesBfAcXGqJeqSkgCW3/PcYVnYY4yoSPFWX3E8KWgjn4CjyzGdXobTYJRxw4O2pd/wakG2ncgLPRz43OxPHpOTvrKZRD/4FSDQvfeqpT6tUpXFoipUIHyW/rotHX7FC6dAcc=
  • Domainkey-status: good (test mode)
  • Mailing-list: list philly-lambda@googlegroups.com; contact philly-lambda-owner@googlegroups.com
  • Reply-to: philly-lambda@googlegroups.com
  • Sender: philly-lambda@googlegroups.com

I had an insight that a couple of people have encouraged me to share...

Joe doesn't come out and say it in the book, but when he explains
the <code>receive</code> call, he leaves out a particular why that
didn't hit me right away.  To paraphrase chapter 8:

  - a timer is started if there is an after section.

  - the first message is taken from the mailbox (when one arrives)
  and if a pattern matches the message, it's consequent clause is
  executed

  - if none of the patterns match the message, it is moved to a
  "save queue" and the remaining messages in the mailbox are tried
  against the patterns

  - if none of the messages in the mailbox match a pattern, the
  process is suspended (the receive blocks) until a new
  message arrives - when a new message arrives, the messages in the
  save queue are not reprocessed (yet)

  - as soon as a pattern matches a (newly) received message, all the
  messages from the save queue are put back into the mailbox.

  - if a timer elapses while receive is blocked waiting
  for a message, then the consequent block in the after
  are executed and all the saved messages are put back into the
  process' mailbox


I re-read it a couple of times trying to figure out why the save
queue wasn't re-added to the mailbox even if no pattern had matched.

Then (in the shower of course) I made a connection with the fact
that Erlang is a functional programming language.  It isn't purely
functional, you can track state, but you can't, for instance, change
the value of a variable once bound (within the same scope).

If no messages in the mailbox are matched against any of the
patterns in receive, then there were no statements executed, and there
was no possible change to the state of the process itself, so there is
no need to replay the messages until something happens which _could_
have changed the state of the process.  This was good, it has made me
re-think some of the other concurrent code I'm working with.

Reading the Erlang book is definitely paying off.


Kyle

-- 
------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
kyle.burton@gmail.com
http://www.neverlight.com/~mortis
------------------------------------------------------------------------------

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Philly Lambda" group.
To unsubscribe from this group, send email to philly-lambda-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/philly-lambda?hl=en
-~----------~----~----~----~------~----~------~--~---