On Wed, 17 Jun 2009, Angel Pais wrote: > New results: > Current workarea: 1 alias: TST1 (verify:0) used: Y > All active workareas in thread workspace: > workarea: 1 alias: TST1 > ZeroSpaceList: [TST1] > WorkSpaceList: > > Current workarea: 2 alias: TST1 (verify:1) used: Y > All active workareas in thread workspace: > workarea: 1 alias: TST1 > workarea: 2 alias: TST1 > ZeroSpaceList: [TST1]
As I expected this code breaks unique aliasing and we have two workareas with the same alias _TST1 It also shows yet another interesting thing. The workareas from ZEROSPACE are not fully detached from ZEROSPACE before attaching to current thread WOKRSPACE but are visible in both ones. It also shows that xbase++ does not register in current thread namespace aliases for iterated ZEROSPACE areas. > WorkSpaceList: > and then is aborts with this error: > ------------------------------------------------------------------------------ > ERROR LOG of "C:\experimentos\test\Test.exe" Date: 06/17/2009 15:20:37 > oError:description : Error in array index > oError:operation : WorkspaceList > ------------------------------------------------------------------------------ > Called from DOTEST(29) > Called from (B)MAIN(10) > Called from MAIN(10) This error appears inside xbase++ code and probably is caused by not fully registered in current thread WORKSPACE iterated workarea from ZEROSPACE. But I only guess. Above with the second test results show that such deeper operations on ZEROSPACE and WORKSPACE gives unexpected results in xbase++. It's rather bad news because we haven't started yet tests for concurrent access. But I cannot say that I'm surprised. I expected that WorkSpaceEval() for ZEROSPACE workareas can open doors for code which can exploit some unexpected and unpleasure behavior. Thank you for your tests. Maybe someone else can say sth more about it. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
