[racket] Places, Channels as Events. Labeling Places.

Using a Place or a Place-Channel as a sync event returns the value of a
place-channel-get and not the Place itself.

Most events return the actual `thing' which one sync'd on.  This is not
true with places and channels, one gets the message itself.

The conundrum is identification of which Place / Place-Channel actually
fired.  Places themselves have no real mechanism supporting GUID labeling
or even simple naming/labeling.   There is no (place-name my-place) or
ability to assign an identifier upon creation.  There is documented support
for Place and Place-Channel equality.  So one can work around all this at
the app code level, i.e. implement their own labeling system for Places.

However assuming a roll your own labeling system there is still
the anonymity of a place / place-channel when used as a sync event issue.

(let ((msg (sync pl-1 pl-2 pl-3))))
   ;; no idea from which place msg came from, unless explicitly recorded in
the msg itself.
   ;; e.g. (Msg-sender msg) -> my home brewed Place-GUID

Compare and contrast with ports used as an event.  A port used as a sync
event results in the port itself upon which one can do whatever this
knowledge.  For example, I might opt *not* to read the port as this time,
even unilaterally close it without reading.

Consider the following parallel, asynchronous request/response idiom.

Given N request msgs and P places, issue one request message per ready
place. (Ready in the sense it is not processing a request.)

I want something like

(let loop ((msgs ...))
  ...
  (let ((ready-place (sync p1 p2 p3)))
        (process-response (place-channel-get ready-place))
        (process-request ready-place (car msgs))
        (loop (cdr msgs))

How would one approach something like this given `sync' not returning the
ready place but the received msg from some anonymous place which was ready.



Thanks,

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121213/cfaef4fc/attachment.html>