[cl-muproc-devel] Re: [PATCH] Adding Erlang-style timeout to MUMSG-RECEIVE

Klaus Harbo 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.
> Syntax:
> 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.
> Example:
> (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

    (muproc-with-timeout (...)
      (mumsg-receive (...)

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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3368 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mailman.common-lisp.net/pipermail/cl-muproc-devel/attachments/20060713/47d973f8/attachment.bin>

More information about the cl-muproc-devel mailing list