May 2012 - bordeaux-threads-devel - mailman3.common-lisp.net

[Bordeaux-threads-devel] CONDITION-WAIT with timeout
by Thomas Munro 14 Sep '13

14 Sep '13

Hi Are there any plans to support a timeout for bordeaux-threads:condition-wait? The implementations I'm aware of support this threading primitive: * ABCL could presumably do it since Java Object.wait can take a timeout * SBCL supports it using sb-thread:condition-wait with keyword :timeout [1] * anything with POSIX threads underneath could use pthread_cond_timedwait The main variation seems to be between those implementations that use an absolute time and those that use a relative time (how long to wait in milliseconds for example). Since I think I need this feature I might try to write a patch to do this for ABCL and SBCL if there is nothing already in the works (unless there is some technical problem I'm not seeing?) Thanks Thomas Munro [1] http://random-state.net/log/3523852985.html

3 6

Re: [Bordeaux-threads-devel] Deprecating recursive locks
by Anton Vodonosov 10 May '12

10 May '12

18.04.2012, 01:48, "Anton Vodonosov" <avodonosov(a)yandex.ru>: > If the public API is changed in a not-backward-compatible way, I would > suggest to release new ASDF system (bordeaux-threads2), and > leave the old version available in quicklisp forever. > > People who are ready to use new version, just add bordeaux-thread2 > into their ASDF dependency. Others are able to use old version. > > This is a good practice. And it costs nothing. > > Some links on this subject: > http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-l… > http://semver.org/ How to handle backward compatibility of bordeaux-threads if the API is changed is up to the maintainer. Still, I think the approach I suggest may be a good solution for lisp libraries evolution, and I would like to present some arguments to support this approach. 18.04.2012, 08:15, "Attila Lendvai" <attila.lendvai(a)gmail.com>: > IMHO it's not a good practice and it does cost complexity/noise. > > you lose the clarity around the digital representation(s) of the > identity of the library. there's only one b-t library, and the fact > that it has changed in a way that made it incompatible with something > else does not change its identity. No, I only suggest to create separate ASDF system and package for new version of the API. It is not uncommon for lisp project to have several ASDF systems and packages. Should these packages be delivered in the same tarball? They may, but non necessary. (depending what is more convenient for the maintainers). As for the library identity, it can remain the same. What is meant by the library identity and how it is used? Project home page will remain the same, for example, mailing list is the same. I.e. it still remains the same project. If we had two bordeaux-threads versions, one with recursive locks, and one without, why not allow suers to name exactly what API their programs need. 22.04.2012, 18:41, "Stelian Ionescu" <sionescu(a)cddr.org>: > On Wed, 2012-04-18 at 01:48 +0400, Anton Vodonosov wrote: >> Some links on this subject: >> http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-l… > That post contains a good analysis of the problem, but then gives the > worst possible advice to solve it Why? At least, this statement is to strong - one can easily create 10 advices worse than the post gives :) If speak seriously, in my opinion referring major version, i.e. specific API, is a good advice. >> http://semver.org/ > Point 5 says "Major version zero (0.y.z) is for initial development. > Anything may change at any time. The public API should not be considered > stable". So no problem there I do not mean we have problem because we contradict some text. I mean that if we have practical problem that N systems will stop to compile after the b-t API changes, leaving the old "frozen" version of API available for these libraries may be a good practical solution for this problem. And the approach of distinguishing changes which modify public API from ones which do not modify the public API is not new. Thus the links, and more examples may be found. IMHO this approach frees the library API to evolve easily, without requiring efforts from the library maintainers, and at the same time not breaking any other systems. Best regards, - Anton

1 0

Re: [Bordeaux-threads-devel] Deprecating recursive locks
by Leslie P. Polzer 03 May '12

03 May '12

Stelian Ionescu wrote: > They're an ugly hack, as described their inventor David Butenhof > (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by > all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive > lock, but it's not a posix recursive lock), so I was thinking of making > a 1.0 release in which to remove them altogether. > > What do you think ? I think it's a bad idea. For me rapid prototyping is an important part of Lisp, and recursive locks support this approach. What Butenhof basically holds against them is that you're not looking at your threading code closely enough. But in the beginning stages of a project I actually might not want to do that. Doing away with them would be premature optimization. Add a note of caution to the docstring if you're that concerned, but don't remove them. Leslie -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

2 1

[Bordeaux-threads-devel] Deprecating recursive locks
by Stelian Ionescu 03 May '12

03 May '12

They're an ugly hack, as described their inventor David Butenhof (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive lock, but it's not a posix recursive lock), so I was thinking of making a 1.0 release in which to remove them altogether. What do you think ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

7 15