headers
Sam Steingold | 1 Nov 2009 07:52
Picon

Re: -PRELIMINARY

> * Vladimir Tzankov <igmnaxbi <at> tznvy.pbz> [2009-10-31 20:15:36 +0200]:
>
> There is general (non MT) problem with this. If we do:
>
> [1]> (intern "SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY" "COMMON-LISP")
>
> ** - Continuable Error
> INTERN("SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY"): #<PACKAGE
> COMMON-LISP> is locked
> If you continue (by typing 'continue'): Ignore the lock and proceed
> The following restarts are also available:
> ABORT          :R1      Abort main loop
> Break 1 [2]> continue
> COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY ;
> NIL
> [3]> (do-symbols (sym "COMMON-LISP")
>   (when (string-equal "SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY"
> (symbol-name sym))
>     (print sym)))
>
> COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
> COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
> NIL
> [4]>
>
> We got two distinct internal symbols (caused by continuable error in
> package.d:intern()).
> In single thread build it does not happen normally (unless caused as
> above) since sys::symbol-suffix unlocks the package. With threads
> there are races on package lock bit and (rarely) we get this behavior
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruno Haible | 1 Nov 2009 11:28

Re: -PRELIMINARY

Hi Sam, Vladimir,

> > * Vladimir Tzankov <igmnaxbi <at> tznvy.pbz> [2009-10-31 20:15:36 +0200]:
> >
> > There is general (non MT) problem with this. If we do:
> >
> > [1]> (intern "SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY" "COMMON-LISP")
> > ...
> > We got two distinct internal symbols (caused by continuable error in
> > package.d:intern()).

Indeed, this is a bug: it violates the consistency rules of the
package system.

> > In single thread build it does not happen normally (unless caused as
> > above) since sys::symbol-suffix unlocks the package. With threads
> > there are races on package lock bit and (rarely) we get this behavior
> > (reported by Don and observed by me).

How is this possible? The "package lock bit" is only an indicator whether
the user should confirm some operations or not. If there is a race
regarding the package lock bit, the worst thing that could happen is
that the user was not asked about some operation, or that the user
is being asked where he shouldn't. But if the package consistency
rules get broken, it indicates that the pack_mutex was not taken when
it should have been taken.

> > 2. as Bruno suggested - make preliminary symbols uninterned (actually
> > all symbols that may be interned when warning or continuable error is
> > signaled)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir Tzankov | 1 Nov 2009 12:45
Picon

Re: -PRELIMINARY

On 11/1/09, Bruno Haible <bruno <at> clisp.org> wrote:
>> > * Vladimir Tzankov <igmnaxbi <at> tznvy.pbz> [2009-10-31 20:15:36 +0200]:
>> > In single thread build it does not happen normally (unless caused as
>> > above) since sys::symbol-suffix unlocks the package. With threads
>> > there are races on package lock bit and (rarely) we get this behavior
>> > (reported by Don and observed by me).
>
> How is this possible? The "package lock bit" is only an indicator whether
> the user should confirm some operations or not. If there is a race
> regarding the package lock bit, the worst thing that could happen is
> that the user was not asked about some operation, or that the user
> is being asked where he shouldn't. But if the package consistency
> rules get broken, it indicates that the pack_mutex was not taken when
> it should have been taken.

When thread A waits to acquire pack_mutex in intern(), another thread
B can set lock bit (finishing interning another symbol). After thread
A gets the mutex it will see package as locked regardless that in it's
context earlier it was unlocked.

>> > 3. manage package locks per-thread instead of global single bit (we've
>> > discussed it before and did not go with it)
>
> Yes, among the two uses of package locks
>   a) the user wants to globally allow/disallow modifications to a package,
>   b) the code wants to avoid a user interaction for a specific
>      modification to a package,
> the second one can, in a multithread world, also unintentionally allow
> modifications in other threads. In order to fix this, every package
> should not only have a pack_locked_p bit (for case a) but also possess
(Continue reading)

Permalink | Reply | 0 comments |
headers
clisp-cvs-request | 1 Nov 2009 13:03
Picon

clisp-cvs Digest, Vol 43, Issue 1

Send clisp-cvs mailing list submissions to
	clisp-cvs <at> lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	clisp-cvs-request <at> lists.sourceforge.net

You can reach the person managing the list at
	clisp-cvs-owner <at> lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."

CLISP CVS commits for today

Today's Topics:

   1. clisp/src ChangeLog,1.7184,1.7185 package.d,1.134,1.135
      (Vladimir Tzankov)
   2. clisp/src ChangeLog,1.7185,1.7186 makemake.in,1.889,1.890
      (Sam Steingold)

----------------------------------------------------------------------

Message: 1
Date: Sat, 31 Oct 2009 17:37:34 +0000
From: Vladimir Tzankov <vtz <at> users.sourceforge.net>
Subject: clisp/src ChangeLog,1.7184,1.7185 package.d,1.134,1.135
To: clisp-cvs <at> lists.sourceforge.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Cohen | 2 Nov 2009 02:41
Favicon

mt question/problem


I may have asked something like this before, but ...

(mt:make-thread 
 (lambda () 
   (format t "testing: ~a" 
        (multiple-value-list (ignore-errors (list *print-pretty* c))))) 
 :name (format nil "foo" ) 
 :initial-bindings 
 (print (loop for x on 
                  (list 'c 'c) 
                  by #'cddr collect 
                  (cons (car x) (list 'quote (cadr x)))))) 

((C QUOTE C))  
#<THREAD "foo"> 
Break 2 [11]> testing:  
(NIL 
 :LAMBDA: variable C has no value 
)

Why is the variable C unbound in the thread when the initial bindings
list seems to contain a value for it?

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
(Continue reading)

Permalink | Reply | 14 comments |
headers
Sam Steingold | 2 Nov 2009 04:12
Picon

Re: mt question/problem

> * Don Cohen <qba-fbheprsbetr-kkm <at> vfvf.pf3-vap.pbz> [2009-11-01 17:41:30 -0800]:
>
> I may have asked something like this before, but ...
>
> (mt:make-thread 
>  (lambda () 
>    (format t "testing: ~a" 
>         (multiple-value-list (ignore-errors (list *print-pretty* c))))) 
>  :name (format nil "foo" ) 
>  :initial-bindings 
>  (print (loop for x on 
>                   (list 'c 'c) 
>                   by #'cddr collect 
>                   (cons (car x) (list 'quote (cadr x)))))) 
>  
> ((C QUOTE C))  
> #<THREAD "foo"> 
> Break 2 [11]> testing:  
> (NIL 
>  :LAMBDA: variable C has no value 
> )
>
> Why is the variable C unbound in the thread when the initial bindings
> list seems to contain a value for it?

because initial-bindings are for global specials:

[1]> (defparameter c 23)
C
[2]> (mt:make-thread
(Continue reading)

Permalink | Reply | 13 comments |
headers
Sam Steingold | 2 Nov 2009 04:25
Picon

COMPILER-DIAGNOSTICS:USE-HANDLER

compile and compile-file now use the CLCS for their diagnostics.
there is even some docs, see
<http://clisp.podval.org/impnotes/compilation.html#compile-errors>.
it looks decent so far (please do get cvs head and try it yourself):

[6]> (compile-file "../../bugs/c-error")
;; Compiling file /home/sds/src/clisp/bugs/c-error.lisp ...
** - Continuable Error
in F in line 1 : Code contains dotted list (BLOCK F . X)
If you continue (by typing 'continue'): Ignore the error and proceed
The following restarts are also available:
ABORT          :R1      Abort main loop
Break 1 [7]> :c
WARNING: in F in line 1 : variable X is not used.
         Misspelled or missing IGNORE declaration?
** - Continuable Error
in C in lines 3..7 : CASE: the T clause must be the last one:
     (CASE X (1 2) (T 4) (5 6))
If you continue (by typing 'continue'): Ignore the error and proceed
The following restarts are also available:
ABORT          :R1      Abort main loop
Break 1 [8]> :c

** - Continuable Error
in H in lines 9..11 : Illegal syntax in LET/LET*: (A A A)
If you continue (by typing 'continue'): Ignore the error and proceed
The following restarts are also available:
ABORT          :R1      Abort main loop
Break 1 [9]> :c
;; Deleted file /home/sds/src/clisp/bugs/c-error.fas
(Continue reading)

Permalink | Reply | 0 comments |
headers
clisp-cvs-request | 2 Nov 2009 13:04
Picon

clisp-cvs Digest, Vol 43, Issue 2

Send clisp-cvs mailing list submissions to
	clisp-cvs <at> lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	clisp-cvs-request <at> lists.sourceforge.net

You can reach the person managing the list at
	clisp-cvs-owner <at> lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."

CLISP CVS commits for today

Today's Topics:

   1. clisp/src ChangeLog,1.7186,1.7187 error.d,1.172,1.173
      (Sam Steingold)
   2. clisp/src ChangeLog, 1.7187, 1.7188 compiler.lisp, 1.351,
      1.352 condition.lisp, 1.100, 1.101 (Sam Steingold)
   3. clisp/src ChangeLog, 1.7188, 1.7189 compiler.lisp, 1.352,
      1.353 condition.lisp, 1.101, 1.102 (Sam Steingold)
   4. clisp/doc Symbol-Table.text, 1.31, 1.32 impbody.xml, 1.578,
      1.579 impent.xml, 1.359, 1.360 (Sam Steingold)

----------------------------------------------------------------------

Message: 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Cohen | 2 Nov 2009 18:45
Favicon

Re: mt question/problem

Sam Steingold writes:
 > > * Don Cohen <qba-fbheprsbetr-kkm <at> vfvf.pf3-vap.pbz> [2009-11-01 17:41:30 -0800]:
 > > Why is the variable C unbound in the thread when the initial bindings
 > > list seems to contain a value for it?
 > because initial-bindings are for global specials:
I don't see anything about this in the doc.
What's the difference between a global special and any other kind?
How does :initial-bindings compare to something like
(let ((vars '(a b c))(vals (list a b c)))
 (mt:make-thread 
  (lambda ()
   (progv vars vals ...))))

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel
Permalink | Reply | 12 comments |
headers
Vladimir Tzankov | 2 Nov 2009 20:14
Picon

Re: mt question/problem

On 11/2/09, Don Cohen <don-sourceforge-xxz <at> isis.cs3-inc.com> wrote:
> Sam Steingold writes:
>  > > * Don Cohen <qba-fbheprsbetr-kkm <at> vfvf.pf3-vap.pbz> [2009-11-01 17:41:30
> -0800]:
>  > > Why is the variable C unbound in the thread when the initial bindings
>  > > list seems to contain a value for it?
>  > because initial-bindings are for global specials:
> I don't see anything about this in the doc.
> What's the difference between a global special and any other kind?

defparameter, defvar and proclaimed specials cause per value cell to
be allocated for symbols. Special variables may have different
bindings in different threads.

> How does :initial-bindings compare to something like
> (let ((vars '(a b c))(vals (list a b c)))
>  (mt:make-thread
>   (lambda ()
>    (progv vars vals ...))))

If A, B and C are not special variables they will not have per thread
allocated value cells - bindings that progv will establish will be
shared between all threads (values of A,B and C in all threads will be
the same).

Note also that vars and vals values will be shared between two threads
(in case above it's not important) - in order to avoid this (let
((vars vars) (vals vals)) (mt:make-thread ...)) may be used.

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 10 comments |

Gmane