On Mon, 22 Sep 2008, Szak�ts Viktor wrote:
Hi all interested in PUBLIC like in xBase++
Now user can fully control the memavars inheritance even separately
for public and private vars. IMHO it's very flexible and allows
to use many of existing code using memvars without rewirting it
for MT mode so seems to be better then xBase++ implementation.
Sharing only public with existing xBase++ code emulates it quite
well with one exception. If child thread create new PUBLIC variable
then it will not be visible in parent thread if it didn't have such
variable allocated when thread was created. F.e.:
#include "hbthread.ch"
memvar PUB1, PUB2
proc main()
public PUB1 := "main:pub1"
? "parent:"
? type( "PUB1" ), iif( type( "PUB1" ) != "U", PUB1, "" )
? type( "PUB2" ), iif( type( "PUB2" ) != "U", PUB2, "" )
hb_threadJoin( hb_threadStart( HB_THREAD_INHERIT_PUBLIC, @thFunc() ) )
? "parent:"
? type( "PUB1" ), iif( type( "PUB1" ) != "U", PUB1, "" )
? type( "PUB2" ), iif( type( "PUB2" ) != "U", PUB2, "" )
return
proc thFunc()
public PUB1 := "thread:pub1"
public PUB2 := "thread:pub2"
? "child:"
? type( "PUB1" ), PUB1
? type( "PUB2" ), PUB2
return
This code in Harbour shows:
parent:
C main:pub1
U
child:
C thread:pub1
C thread:pub2
parent:
C thread:pub1
U
If I understand well xbase++ documentation then in this language it should
show:
parent:
C main:pub1
U
child:
C thread:pub1
C thread:pub2
parent:
C thread:pub1
C thread:pub2
BTW If someone can confirm this then it will be nice. Otherwise we may
talk about sth what does not exists.
In all xbase++ documentations I've seen so far the important for me
things are missing and only basic behavior is described. Just like in
dbRelease()/dbDetach(). What does xbase++ with relations and active
locks (RLOCK()/FLOCK() when WA is released?
So public variable created by child thread is also visible in all other
threads even if it didn't exist when thread is created.
Now I'm thinking about real application usage. I cannot touch any
shared variables without protection. It means that If I want to use it
in parrent thread I have to know its name. If I know it then I can simply
declare it by:
public <varname>
before I'll start the thread just like pub1 was declared in example above.
Here new INIT PUBLIC statement can be very nicely used to initialize all
such PUBLIC variables automatically when program starts. Of coures if
someone want to create such global to process public variables.
After rethinking the problem I'm finding xbase++ behavior as limitation
not a feature because now each thread can use it's own set of public
variables, known only for this thread and its child threads which can
be shared between them if necessary and it does not effect parent thread.
If we exactly replicate the xbase++ behavior we will stronlgy reduce
PUBLIC functionality to sth what can be used only by application author
which knows all PUBLIC variable names and does not have to worry about
name conflicts with 3-rd party code. The final result of such model
has also yet another bad side effect. Each access to public variable
have to be protected by MUTEX if this is not readonly var what makes
some other complications.
In summary I'm finding current Harbour behavior better.
I can implement xBase++ like solution even quite easy though with some
additional memory cost - we will have to store PUBLICs handles directly
in global dynamic symbol table which is not thread local. I've just check
it. Anyhow it will not be possible to keep current optional memvar
separation fully working. Just simply each thread if wants to see public
variables have to access also common to all thread PUBLIC area and has
to be able to create threads which can create in this area effecting all
other threads even if user needs full separation. Additionally it will
force using hidden for user mutex synchronization used each time global
public area is accessed/assign to avoid internal structure corruption
what will reduce the performance.
In real applications it's very minor problem and here I do not see good
reason reduce functionality, security and speed and only to replicate
exact xbase++ behavior.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
