I'm not sure when it happened but between my June 5 and July 27 builds,
#'LOAD no longer can handle wildcards in *LOAD-PATHS*. I assume
this is due to the code in #'SYSTEM::SEARCH-FILE which now just does
#'PROBE-FILE on constructed pathnames.
[1]> (probe-file "/home/foo/**/bar.lisp")
*** - PROBE-FILE: wildcards are not allowed here: #P"/home/foo/**/bar.lisp"
--
Barry Fishman

Hello,
Here are my thoughts on the LISP heap management with multithreading.
I am still not aware of many internal details and possible pitfalls -
so advices are welcomed.
1. GC.
The GC will be protected with spinlock (possibly more efficient than mutex).
During GC all thread will be suspended at "safe" points (described below).
Suspension will be through mutex or spinlock - per thread.
The suspension and GC will be performed in the context of the thread
that caused the GC.
Is it ok to delay the suspension after the mark phase?
Still no objects are moved. All other threads may continue to run
(unless they do not try to allocate something and do not care about
the mark bit(s)).
Are there non-local exits from the GC?
What happens with signals during GC - looks like they are "disabled"?
(Pascal Bourguignon posted this interesting paper:
http://www.cs.technion.ac.il/~erez/Papers/parallel-compaction.ps)
2. Allocations.
I would like to have spinlock per heap type. In this way the
allocations on a single heap will not block allocation on other types
(unless GC is invoked). I am not sure that this is possible for all
memory models but SVPW_PURE ones are good candidates.
Implementing this requires changes to mem structure, spvw_allocate.d
and other places that rely on accessing members of mem different than
heap specific ones. Currently I do not feel I am aware of all the
details in order to implement it quickly - so it will remain as TODO
item.
However as a beginning:
1. single spinlock protects the whole mem structure (all heaps).
2. every thread should acqiure it in order to allocate anything
3. the thread that causes the GC will suspend all others before invoking it.
4. every thread should define so called "safe" points at which it can
be suspended with no risk. these places will be:
4.1. any call to allocate_xxxxxx()
4.2. begin_system_call (what happens if pointers to LISP heap are passed?)
4.3. (*) we need some other place in order to be able to suspend
forms like: (loop). Probably the interrupt() macro is good candidate?
"safe" points concept is similar to the cancellation points
(pthread_testcancel()) in pthreads.
BR
Vladimir

Raymond Toy (RT/EUS) wrote:
> Sam Steingold wrote:
>> Elliott Slaughter wrote:
>>> Would it be possible for clisp-cvs to be unlinked with clisp-devel?
>>> This would make receiving the cvs messages voluntary for those on
>>> clisp-devel and would give developer/users more control over exactly
>>> which messages they want to read.
>> are others bothered by the cvs digests on this list too?
>
> No, not really. I just set up a filter to drop all the clisp-cvs
> digests into its own folder.
>
> What I find more annoying is looking at the sourceforge bug tracker
> mailes and see that a bug is closed, but no explanation of why, except
> for the canned message saying it's closed (or fixed). Then I get to
> wade through the cvs digests to see what was fixed.
when a bug is fixed, ChangeLog and NEWS mention the bug number, so you
just search for the bug number in the cvs mails.

Sam Steingold wrote:
> Elliott Slaughter wrote:
>> Would it be possible for clisp-cvs to be unlinked with clisp-devel?
>> This would make receiving the cvs messages voluntary for those on
>> clisp-devel and would give developer/users more control over exactly
>> which messages they want to read.
>
> are others bothered by the cvs digests on this list too?
No, not really. I just set up a filter to drop all the clisp-cvs
digests into its own folder.
What I find more annoying is looking at the sourceforge bug tracker
mailes and see that a bug is closed, but no explanation of why, except
for the canned message saying it's closed (or fixed). Then I get to
wade through the cvs digests to see what was fixed.
Ray

> Date: Mon, 28 Jul 2008 22:11:30 +0300
> From: "Vladimir Tzankov" <vtzankov@...>
> Subject: Re: CLISP multithreading (patch included)
> To: "Reini Urban" <rurban@...>
> Cc: clisp-devel@...
> Message-ID: <2295f2fa0807281211pd91e065t6eb1208b8a6e9653@...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Reini,
>
> > Vladimir Tzankov schrieb:
> >>
> >> First of all this is very long mail about multithreading in CLISP and
> >> it's implementation.
> >
> > BTW: I hope you know that you missed around $4500 USD
> > if you are young enough to be a student.
> > This was a potential Google Summer of Code project, and one of the hardest.
> > Nobody applied for it.
>
> I've not missed anything - for some years I am not a student anymore :).
> (for some years I have been using clisp and liked it - now with the
> multicore cpu-s it will be nice to have threads - not sure how i'll
> progress - now studying the GC implementation)
Have a look at this paper:
http://www.cs.technion.ac.il/~erez/Papers/parallel-compaction.ps
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.

2008/7/28 Sam Steingold <sds@...>:
> Elliott Slaughter wrote:
>> Would it be possible for clisp-cvs to be unlinked with clisp-devel?
>> This would make receiving the cvs messages voluntary for those on
>> clisp-devel and would give developer/users more control over exactly
>> which messages they want to read.
>
> are others bothered by the cvs digests on this list too?
I'm happy.