|
»
Re: -PRELIMINARY
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: -PRELIMINARY
by Vladimir Tzankov
::
Rate this Message:
Sam,
>> where is this SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY symbol created? >> >> [1]> (find-all-symbols "SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY") >> NIL >> [2]> (warn "") >> WARNING: >> NIL >> [3]> (find-all-symbols "SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY") >> (COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY) 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 (reported by Don and observed by me). Possible solutions: 1. in intern() - first check whether the package is locked (not sure this will not break something in reader). 2. as Bruno suggested - make preliminary symbols uninterned (actually all symbols that may be interned when warning or continuable error is signaled) 3. manage package locks per-thread instead of global single bit (we've discussed it before and did not go with it) 4. ? Vladimir ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/clisp-devel |
|
|
Re: -PRELIMINARY
by Sam Steingold
::
Rate this Message:
> * Vladimir Tzankov <igmnaxbi@...> [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 > (reported by Don and observed by me). > > Possible solutions: > 1. in intern() - first check whether the package is locked (not sure > this will not break something in reader). how about yet another find_symbol after cerror_package_locked? this might be ugly, but it does not affect performance (cerror_package_locked should dwarf any find_symbol). --- package.d.~1.135.~ 2009-10-31 23:32:03.000000000 -0400 +++ package.d 2009-11-01 01:50:51.000000000 -0500 @@ -846,7 +846,15 @@ modexp maygc uintBWL intern pushSTACK(coerce_ss(*string_)); cerror_package_locked(S(intern),*pack_,STACK_0); *string_ = popSTACK(); + /* CERROR may do interesting things: it goes through CLCS, i.e., CLOS, + and can compute effective methods and thus create symbols, so... */ + result = find_symbol(*string_,invert,*pack_,sym_); + if (result) { + *newsym_ = *sym_; /* store at gc safe location */ + result &= 3; /* found -> finished */ } + } + if (result == 0) { if (invert) *string_ = string_invertcase(*string_); *string_ = coerce_imm_ss(*string_); /* string --> immutable simple-string */ @@ -856,6 +864,7 @@ modexp maygc uintBWL intern make_present(*newsym_,*pack_); /* intern into this package */ clr_break_sem_2(); /* allow breaks */ } + } }); *sym_ = *newsym_; skipSTACK(3); /* string, pack & newsym */ at least the behavior you describe above is now gone. > 2. as Bruno suggested - make preliminary symbols uninterned (actually > all symbols that may be interned when warning or continuable error is > signaled) I am somewhat worried about leaks: it seems that these symbols may live forever and be created over and over, so we get a few uncollectable uninterned identically named symbols. > 3. manage package locks per-thread instead of global single bit (we've > discussed it before and did not go with it) package locks are distribution integrity tools. it does not make sense for their status to depend on the thread. however, unlocking it should be done inside WITH_LISP_MUTEX_LOCK. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 9.04 (jaunty) http://thereligionofpeace.com http://openvotingconsortium.org http://ffii.org http://www.memritv.org http://dhimmi.com http://palestinefacts.org MS Windows: error: the operation completed successfully. ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/clisp-devel |
|
|
Re: -PRELIMINARY
by Bruno Haible
::
Rate this Message:
Hi Sam, Vladimir,
> > * Vladimir Tzankov <igmnaxbi@...> [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) If you have a problem inside the INTERN function, no modification of the *.lisp files can fix it. > how about yet another find_symbol after cerror_package_locked? This goes into the right direction. Moreover, doing a cerror_package_locked inside WITH_LISP_MUTEX_LOCK is probably not desired, because cerror_package_locked can take a long time, and you don't want other threads to be blocked during that time. I would - relinquish the pack_mutex before calling cerror_package_locked, - after cerror_package_locked, acquire the pack_mutex again, then check using find_symbol and pack_locked_p what the current situation is. > > 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 a symbol that can be dynamically bound to NIL or T in any thread (for case b). But this is a different issue; first the bug regarding the package consistency rules needs to be fixed. Bruno ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/clisp-devel |
|
|
Re: -PRELIMINARY
by Vladimir Tzankov
::
Rate this Message:
On 11/1/09, Bruno Haible <bruno@...> wrote:
>> > * Vladimir Tzankov <igmnaxbi@...> [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 > a symbol that can be dynamically bound to NIL or T in any thread (for > case b). Adding internal symbol with per thread allocated value cell (i.e. special variable) to package struct solves both uses. It has global value (for case a) and can be per thread bound (for case b). Vladimir ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/clisp-devel |
| Free embeddable forum powered by Nabble | Forum Help |
