[cl-muproc-devel] Re: [PATCH] Adding Erlang-style timeout to MUMSG-RECEIVE
klaus at mu.dk
Thu Jul 13 07:17:41 UTC 2006
Hi Vladimir --
Vladimir Sekissov wrote:
> Good day,
> The patch in the attachment is adding Erlang-style timeout clause to
> MUMSG-RECEIVE. TIMEOUT is active only on packet-matching phase
> opposite to WITH-TIMEOUT which can break in the middle of message
> processing clause body.
> Semantic is the same as of TIMEOUT in Erlang RECEIVE statement.
> (TIMEOUT TIMEOUT-VALUE &body TIMEOUT-BODY)
> When TIMEOUT-VALUE is evaluated to:
> NIL or 0 -- non-blocking receiving. TIMEOUT-BODY is evaluated
> immediately if there is no pending input or all packet-matcing clauses
> are failed;
> NUMBER -- wait NUMBER seconds in packet-matching phase;
> T (generic boolean) -- the same as Erlang INFINITY, wait before
> matching input.
> (mumsg-receive (from)
> ((request) t
> (push request acc))
> (timeout 0
> (push :receiver-timed-out acc)
> (%enqueue% mbox (nreverse acc))))
Until now, I have gotten by using
but I believe this is a definite improvement: It allows you to scan the input
queue for specific content without blocking or waiting at least some period of
time. I think that is valuable. (There are probably other things as well.)
Also, I have tried it on Lispworks, and seems to work as advertised.
> Tested with SBCL/CMUCL.
> For CMUCL you need bug-fixed TIMER package and bug-fixing patch for
> Both are in the attachments.
This concerns me somewhat. I admit I don't know much about BORDEAUX or the
timer library you include, but you mention that they are bug-fixed -- does that
mean that they'll need to be included in the cl-muproc distribution? Does the
bug-fixing mean that we've effectively branched these libraries and that we'll
need to maintain them separately from now on? I'd appreciate if you could
enlighten us a bit here...
> There is possible conflict in simultaneous use of TIMEOUT in RECEIVE
> and WITH-TIMEOUT if implementation-dependent timers don't care about
> recursion (one timer can catch a signal from another).
> I fixed this for SBCL/CMUCL but haven't access to LispWorks and OpenMCL.
I'm pretty sure that this works correctly on Lispworks, don't know about OpenMCL.
> Best Regards,
> Vladimir Sekissov
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3368 bytes
Desc: S/MIME Cryptographic Signature
More information about the cl-muproc-devel