From peter at gigamonkeys.com  Fri Dec 18 16:34:15 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Fri, 18 Dec 2009 08:34:15 -0800
Subject: [Bordeaux-threads-devel] with-timeout abstraction leaks a bit?
Message-ID: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>

I was using WITH-TIMEOUT the other day and it seems that it doesn't
quite hide the underlying implementation quite enough: on SBCL it
signals an SBCL-specific condition when it times out. Thus to handle
the timeout you have to either handle that specific condition or
something too broad (like CONDITION). Perhaps BT:WITH-TIMEOUT should
handle the underlying condition and signal a BT-defined condition so
this code can be written portably. I could provide a patch for SBCL
(and probably Allegro) if folks think this is a good idea.

-Peter

-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From martin at lispworks.com  Fri Dec 18 18:48:26 2009
From: martin at lispworks.com (Martin Simmons)
Date: Fri, 18 Dec 2009 18:48:26 GMT
Subject: [Bordeaux-threads-devel] with-timeout abstraction leaks a bit?
In-Reply-To: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>
	(message from Peter Seibel on Fri, 18 Dec 2009 08:34:15 -0800)
References: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>
Message-ID: <200912181848.nBIImQql032707@higson.cam.lispworks.com>

>>>>> On Fri, 18 Dec 2009 08:34:15 -0800, Peter Seibel said:
> 
> I was using WITH-TIMEOUT the other day and it seems that it doesn't
> quite hide the underlying implementation quite enough: on SBCL it
> signals an SBCL-specific condition when it times out. Thus to handle
> the timeout you have to either handle that specific condition or
> something too broad (like CONDITION). Perhaps BT:WITH-TIMEOUT should
> handle the underlying condition and signal a BT-defined condition so
> this code can be written portably. I could provide a patch for SBCL
> (and probably Allegro) if folks think this is a good idea.

I think it would be better to remove WITH-TIMEOUT completely, because it is
too dangerous to use in production code.  It causes a throw from a random
point in the program, so there is no way to use it safely with UNWIND-PROTECT
without extra code to prevent that.

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/



From peter at gigamonkeys.com  Fri Dec 18 19:57:33 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Fri, 18 Dec 2009 11:57:33 -0800
Subject: [Bordeaux-threads-devel] with-timeout abstraction leaks a bit?
In-Reply-To: <200912181848.nBIImQql032707@higson.cam.lispworks.com>
References: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>
	<200912181848.nBIImQql032707@higson.cam.lispworks.com>
Message-ID: <40e4e7e50912181157w2d7147e7ja517f473806ce4cb@mail.gmail.com>

Well, the use I had for it was I needed to wait on a condition
variable with a timeout. I.e. wait until the condition was notified or
a certain amount of time had passed. In Allegro there was a direct way
of doing that but there wasn't in Bordeaux Threads so I had to roll my
own. If Bordeaux Threads wants to provide a way of doing that I'll be
happy (at least for now). Though I'm not sure I see that WITH-TIMEOUT
deserves to be totally removed--you may need to exercise some care
about what you put inside a WITH-TIMEOUT but it seems that it
shouldn't be drastically worse than any code that, say, calls a
user-provided function (which could also signal a condition at a more
or less random time.) Unless you're saying it's hard/impossible to
implement safely within the Lisp implementation. That I wouldn't know
about.

-Peter

On Fri, Dec 18, 2009 at 10:48 AM, Martin Simmons <martin at lispworks.com> wrote:
>>>>>> On Fri, 18 Dec 2009 08:34:15 -0800, Peter Seibel said:
>>
>> I was using WITH-TIMEOUT the other day and it seems that it doesn't
>> quite hide the underlying implementation quite enough: on SBCL it
>> signals an SBCL-specific condition when it times out. Thus to handle
>> the timeout you have to either handle that specific condition or
>> something too broad (like CONDITION). Perhaps BT:WITH-TIMEOUT should
>> handle the underlying condition and signal a BT-defined condition so
>> this code can be written portably. I could provide a patch for SBCL
>> (and probably Allegro) if folks think this is a good idea.
>
> I think it would be better to remove WITH-TIMEOUT completely, because it is
> too dangerous to use in production code. ?It causes a throw from a random
> point in the program, so there is no way to use it safely with UNWIND-PROTECT
> without extra code to prevent that.
>
> --
> Martin Simmons
> LispWorks Ltd
> http://www.lispworks.com/
>



-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From martin at lispworks.com  Mon Dec 21 11:35:52 2009
From: martin at lispworks.com (Martin Simmons)
Date: Mon, 21 Dec 2009 11:35:52 GMT
Subject: [Bordeaux-threads-devel] with-timeout abstraction leaks a bit?
In-Reply-To: <40e4e7e50912181157w2d7147e7ja517f473806ce4cb@mail.gmail.com>
	(message from Peter Seibel on Fri, 18 Dec 2009 11:57:33 -0800)
References: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>
	<200912181848.nBIImQql032707@higson.cam.lispworks.com>
	<40e4e7e50912181157w2d7147e7ja517f473806ce4cb@mail.gmail.com>
Message-ID: <200912211135.nBLBZqfq028149@higson.cam.lispworks.com>

Good luck with that -- handling arbitrary throws in the condition variable
implementation is very difficult to get right :-(

Adding a timeout argument to condition-wait is the best option.

The difference between WITH-TIMEOUT and code that calls user-provided
functions is that you know where these functions are called.

E.g. the call to CLEANUP-2 will be skipped if the timeout occurs inside
CLEANUP-1:

(unwind-protect
    ...
  (cleanup-1)
  (cleanup-2))

Even worse, code like the example below is flawed because the timeout might
occur inside allocate-temp-object, before the variable is set, but after the
temp object has been allocated:

(let (object)
  (unwind-protect
      (progn
        (setq object (allocate-temp-object))
        ...use object...)
    (when object
      (deallocate-temp-object object))))

Fixing these common idioms to work with WITH-TIMEOUT requires some changes to
the code, possibly using macros that block interrupts.

__Martin


>>>>> On Fri, 18 Dec 2009 11:57:33 -0800, Peter Seibel said:
> 
> Well, the use I had for it was I needed to wait on a condition
> variable with a timeout. I.e. wait until the condition was notified or
> a certain amount of time had passed. In Allegro there was a direct way
> of doing that but there wasn't in Bordeaux Threads so I had to roll my
> own. If Bordeaux Threads wants to provide a way of doing that I'll be
> happy (at least for now). Though I'm not sure I see that WITH-TIMEOUT
> deserves to be totally removed--you may need to exercise some care
> about what you put inside a WITH-TIMEOUT but it seems that it
> shouldn't be drastically worse than any code that, say, calls a
> user-provided function (which could also signal a condition at a more
> or less random time.) Unless you're saying it's hard/impossible to
> implement safely within the Lisp implementation. That I wouldn't know
> about.
> 
> -Peter
> 
> On Fri, Dec 18, 2009 at 10:48 AM, Martin Simmons <martin at lispworks.com> wrote:
> >>>>>> On Fri, 18 Dec 2009 08:34:15 -0800, Peter Seibel said:
> >>
> >> I was using WITH-TIMEOUT the other day and it seems that it doesn't
> >> quite hide the underlying implementation quite enough: on SBCL it
> >> signals an SBCL-specific condition when it times out. Thus to handle
> >> the timeout you have to either handle that specific condition or
> >> something too broad (like CONDITION). Perhaps BT:WITH-TIMEOUT should
> >> handle the underlying condition and signal a BT-defined condition so
> >> this code can be written portably. I could provide a patch for SBCL
> >> (and probably Allegro) if folks think this is a good idea.
> >
> > I think it would be better to remove WITH-TIMEOUT completely, because it is
> > too dangerous to use in production code. ?It causes a throw from a random
> > point in the program, so there is no way to use it safely with UNWIND-PROTECT
> > without extra code to prevent that.
> >
> > --
> > Martin Simmons
> > LispWorks Ltd
> > http://www.lispworks.com/
> >
> 
> 
> 
> -- 
> Peter Seibel
> http://www.codersatwork.com/
> http://www.gigamonkeys.com/blog/
> 
> _______________________________________________
> Bordeaux-threads-devel mailing list
> Bordeaux-threads-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
> 

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/



From sionescu at cddr.org  Fri Dec 25 00:39:21 2009
From: sionescu at cddr.org (Stelian Ionescu)
Date: Fri, 25 Dec 2009 01:39:21 +0100
Subject: [Bordeaux-threads-devel] with-timeout abstraction leaks a bit?
In-Reply-To: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>
References: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>
Message-ID: <1261701561.32594.104.camel@blackhole.cddr.org>

On Fri, 2009-12-18 at 08:34 -0800, Peter Seibel wrote:
> I was using WITH-TIMEOUT the other day and it seems that it doesn't
> quite hide the underlying implementation quite enough: on SBCL it
> signals an SBCL-specific condition when it times out. Thus to handle
> the timeout you have to either handle that specific condition or
> something too broad (like CONDITION). Perhaps BT:WITH-TIMEOUT should
> handle the underlying condition and signal a BT-defined condition so
> this code can be written portably. I could provide a patch for SBCL
> (and probably Allegro) if folks think this is a good idea.

I've fixed this: now with-timeout will always signal bt:timeout - which
on SBCL is an alias for sb-ext:timeout

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20091225/5ba2a5b6/attachment.sig>

From sionescu at cddr.org  Fri Dec 25 00:46:20 2009
From: sionescu at cddr.org (Stelian Ionescu)
Date: Fri, 25 Dec 2009 01:46:20 +0100
Subject: [Bordeaux-threads-devel] with-timeout abstraction leaks a bit?
In-Reply-To: <40e4e7e50912181157w2d7147e7ja517f473806ce4cb@mail.gmail.com>
References: <40e4e7e50912180834t2820d1e2ne43d9d0bd9d4563c@mail.gmail.com>
	<200912181848.nBIImQql032707@higson.cam.lispworks.com>
	<40e4e7e50912181157w2d7147e7ja517f473806ce4cb@mail.gmail.com>
Message-ID: <1261701980.32594.111.camel@blackhole.cddr.org>

On Fri, 2009-12-18 at 11:57 -0800, Peter Seibel wrote:
> Well, the use I had for it was I needed to wait on a condition
> variable with a timeout. I.e. wait until the condition was notified or
> a certain amount of time had passed. In Allegro there was a direct way
> of doing that but there wasn't in Bordeaux Threads so I had to roll my
> own. If Bordeaux Threads wants to provide a way of doing that I'll be
> happy (at least for now). Though I'm not sure I see that WITH-TIMEOUT
> deserves to be totally removed--you may need to exercise some care
> about what you put inside a WITH-TIMEOUT but it seems that it
> shouldn't be drastically worse than any code that, say, calls a
> user-provided function (which could also signal a condition at a more
> or less random time.) Unless you're saying it's hard/impossible to
> implement safely within the Lisp implementation. That I wouldn't know
> about.

The problem is that the only general way to implement timeouts is to use
alarm(2) which asks the kernel to send SIGALRM after a certain amount of
time, and mixing signals and condition variables is very prone to errors
- the example given by Martin is a typical case of resource leak caused
by asynchronous unwinds

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20091225/e1d598b5/attachment.sig>

From sionescu at cddr.org  Fri Dec 25 01:56:40 2009
From: sionescu at cddr.org (Stelian Ionescu)
Date: Fri, 25 Dec 2009 02:56:40 +0100
Subject: [Bordeaux-threads-devel] Version 0.7.0 released
Message-ID: <1261706200.12171.14.camel@blackhole.cddr.org>

I've just released version 0.7.0

Significant changes since last release:
* new function JOIN-THREAD
* MAKE-CONDITION-VARIABLE now takes a keyword argument NAME
* *default-special-bindings* now contains an alist mapping symbols to
forms to be evaluated rather than closures to be funcalled
* added *standard-io-bindings*
* support for Clisp and Scieneer Common Lisp
* nickname "threads" was removed because used by Clisp
* dependency on Alexandria(http://common-lisp.net/project/alexandria)

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20091225/d0c208fc/attachment.sig>

From matt.lamari at gmail.com  Wed Dec 30 05:37:16 2009
From: matt.lamari at gmail.com (Matt Lamari)
Date: Tue, 29 Dec 2009 23:37:16 -0600
Subject: [Bordeaux-threads-devel] Lispworks Condition-notify - for the
 latest Bordeaux-threads - please add it to the tip
Message-ID: <4B3AE70C.6010602@gmail.com>

We had a conversation on this a while back.

Same code (as we discussed), diffed against the latest.

The unit-test still passes.

ASD file has to be modded to remove a clash with the default
condition-var struct

Attached are the diff files - I hope they are in the right form.  I'd
like to get this code out there - please let me know if any changes are
required.




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bordeaux-threads.asd.diff
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20091229/762a5529/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: impl-lispworks.lisp.diff
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20091229/762a5529/attachment-0001.ksh>

From matt.lamari at gmail.com  Wed Dec 30 16:12:34 2009
From: matt.lamari at gmail.com (Matt Lamari)
Date: Wed, 30 Dec 2009 10:12:34 -0600
Subject: [Bordeaux-threads-devel] Addendum: Lispworks Condition-notify -
 for the latest Bordeaux-threads - please add it to the tip
In-Reply-To: <4B3AE70C.6010602@gmail.com>
References: <4B3AE70C.6010602@gmail.com>
Message-ID: <4B3B7BF2.6000502@gmail.com>


New diffs - I added "name" to make-condition-variable to match the
spec.  (defun make-condition-variable (&key name) . . . .)



Matt Lamari wrote:
> We had a conversation on this a while back.
>
> Same code (as we discussed), diffed against the latest.
>
> The unit-test still passes.
>
> ASD file has to be modded to remove a clash with the default
> condition-var struct
>
> Attached are the diff files - I hope they are in the right form.  I'd
> like to get this code out there - please let me know if any changes are
> required.
>
>
>
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bordeaux-threads.asd.diff
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20091230/5258d006/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: impl-lispworks.lisp.diff
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20091230/5258d006/attachment-0001.ksh>