[Gbbopen-developer] portable-threads

[Dan Corkill]

> i've recently checked out the repo and saw that the portable-threads
> subproject is a quite complete portable thread lib for cl and also
> looks good.
> 
> unfortunately it's quite complicated to use it for projects (it stops
> loading with some asdf related continuable error; you can't do
> :depends-on :portable-threads directly because it's not a standalone
> .asd). i was wondering if you considered making it a standalone
> lightweight cross-platform threading lib?

Attila,

Quite a while back, we made GBBopen's Portable Threads Interface stand
alone (one file) as part of Will Fitzgerald's CL Gardener's project
(http://wiki.alu.org/Portable_Threads).  [There is also a separate "trip
test" file, test/portable-threads-test.lisp, in GBBopen that does some
stress testing/timing.]

Gary King (gwking at metabang.com) subsequently did an ASDF-install for the
Portable Threads file and added a CLiki page for it.  (GBBopen includes
a different (non-ASDF) module definition/management system, so we don't
do much ASDF work/support).  Anyway, if the ASDF-install of GBBopen's
Portable Threads Interface is broken, Gary is the place to start.

> the opensource community could give you back some useful patches as
> more people start using it. i, for one, could start with a fast
> atomic-incf for sbcl... :)

Yes!!  The atomic-operation entities for SBCL need attention--as does a
better thread-yield...

> if you are not against the idea i could help you in doing the nifty
> details of extracting it into a standalone .asd, setting up the
> project/repo if it's to be in a different repo, possibly a
> common-lisp.net page, etc. but of course strictly by your rules and
> making it clear that it's your code with your licence, etc.

If the ASDF issues can't be resolved with Gary, we should pursue your
suggestion further.  Since it is a single file, I'd prefer to keep it in
the full GBBopen SVN repository (but perhaps making it easier to do a
single-file checkout...).  There are people using other GBBopen "tool
layers"--but not full GBBopen--and keeping the overall GBBopen code
structure makes it easier for them to use some of these tools that are
not fully independent of one another.  Suggestions/ideas are welcomed!

The on-line & PDF documentation for Portable Threads is not separated
from GBBopen (and doing so would limit the cross referencing with other
parts of GBBopen), but we hope that having it as a separate section in a
larger reference is not a major issue.

> also i've heard that someone could not use portable-threads in his
> LLGPL lib because the Apache license is not compatible with LLGPL.
> maybe you could use a more forgiving license in a standalone p-t lib
> if you like the idea.

We don't think that the GBBopen Apache 2.0 license prevents anyone from
using GBBopen (or the Portable Threads Interface) as part of a GPL/LGPL
licensed application (the FSF now states that the Apache 2.0 license is
compatible with GPLv3).  The compatibility debate with Apache 2.0 and
GPLv2 related to the Apache's patent clause.

The "poison pill" patent protection (clause 3) of the Apache 2.0 license
was one of the major reasons we chose to release GBBopen under that
license.  Even the FSF now views the threat of patient litigation as a
big enough issue that they have modified their principled stance against
software patents as one of the major changes made in GPLv3
(http://www.fsf.org/licensing/licenses/quick-guide-gplv3.html):

> > Stronger Protection Against Patent Threats
> >
> > In the 17 years since GPLv2 was published, the software patent
> > landscape has changed considerably, and free software licenses
> > have developed new strategies to address them. GPLv3 reflects
> > these changes too. Whenever someone conveys software covered
> > by GPLv3 that they've written or modified, they must provide
> > every recipient with any patent licenses necessary to exercise
> > the rights that the GPL gives them. In addition to that, if
> > any licensee tries to use a patent suit to stop another user
> > from exercising those rights, their license will be terminated.
> >
> > What this means for users and developers is that they'll be
> > able to work with GPLv3-covered software without worrying that
> > a desperate contributor will try to sue them for patent
> > infringement later. With these changes, GPLv3 affords its
> > users more defenses against patent aggression than any other
> > free software license.

We view clause 3 of the Apache license as highly desirable protection
rather than a burden on use/incorporation/distribution of GBBopen (or
Portable Threads).

Although we strongly recommend against making use of it, we might be
willing to consider adding another special-exception clause to the
GBBopen license that allows someone to use/redistribute GBBopen without
clause 3 of the Apache 2.0 license in effect.  Given the new emphasis
from the Open Source community on this issue, we would prefer to *not*
add this additional special exception.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.