Hi,
Przemysław Czerpak wrote:
The second proposed solution is more flexible, but is not optimal
because it keeps a long mutex lock on "zerospace" internals.
Just like WorkaAreaEval() in xbase++ and it's the reason why I still
haven't added it to SVN code.
There is one very serious problem with alias name modification and
switching workareas between threads. It hardly interacts with RDDs
using remote servers which allows to optimize expressions and execute
them on the server side. It causes that it's necessary to replicate
on the server side all local alias modifications what can seriously
reduce the performance.
If we allow "modification" of alias only on workarea attaching, then we
just have to treat detach as close, and attach as open. Perhaps this can
help to simplify remote RDD optimisations, but I do not have a whole
picture here.
Anyhow current code which tries to follow xbase++ specification
replicated also some xbase++ anomalies (fortunately not all) so it
has to be cleaned and I plan to make.
Your propositions are very interesting but before I'll change anything
in this code I will want to rethink all interactions with RDDs using
remote servers.
I see also some hidden problems, that's why I wanted to make more a
discussion, than a final "I wish" idea proposal.
The first idea that came to my mind was functions:
hArea := HB_DBDETACH( [ cAlias | nWorkArea ])
and
HB_DBATTACH( hArea, [ cAlias ], [ lNewArea ] )
hArea could be any handle to detached workarea, f.e., number, but
collectible pointer is the best choice in case of Harbour. If hArea is
not visible for application than area is closed. A simple HB_DBDETACH()
call without using return value is equivalent to DBCLOSEAREA(). This
hArea can be stored in array together with corresponding alias,
filename, index, open mode, or whatever data, and later simple ASCAN()
can be used to get alias from "zerospace". hArea can also be notified to
some mutex queue and this is equivalent to fWait flag in current
DBREQUEST().
But these two HB_DBDETACH()/HB_DBATTACH() has very different logic from
current xBase++ implementation, so, I did not proposed this. On the
other hand I feel we should use the solution that fits our ideas the
best and is enough flexible to build another logic on the top of it. F.e.:
STATIC saZeroSpace := {}
STATIC shMutex := HB_MUTEXCREATE()
FUNC DBDETACH( cAlias, xCargo )
LOCAL hArea
IF EMPTY(cAlias); cAlias := ALIAS()
ENDIF
hArea := HB_DBDETACH(cAlias)
IF EMPTY(hArea); RETURN .F.
ENDIF
HB_MUTEXLOCK(shMutex)
AADD(saZeroSpace, {hArea, cAlias, xCargo})
HB_MUTEXNOTIFYALL(shMutex)
HB_MUTEXUNLOCK(shMutex)
RETURN .T.
FUNC DBREQUEST( cAlias, lFreeArea, xCargo, lWait )
LOCAL nI, lRet := .F.
HB_MUTEXLOCK(shMutex)
DO WHILE .T.
IF (nI := ASCAN(saZeroSpace, {|X| X[2] == cAlias})) > 0
HB_DBATTACH(saZeroSpace[nI, 1], saZeroSpace[nI, 2], lFreeArea)
xCargo := saZeroSpace[nI, 3]
ADEL(saZeroSpace, nI)
ASIZE(saZeroSpace, LEN(saZeroSpace) - 1)
lRet := .T.
EXIT
ENDIF
IF ! EMPTY(lWait)
HB_MUTEXSUBSCRIBE(shMutex)
ELSE
EXIT
ENDIF
ENDDO
HB_MUTEXLOCK(shMutex)
RETURN lRet
/* This code represents the idea only, it is not tested, can contain
bugs, can be optimized by putting new item position into notify queue,
to avoid ascan of all array for all mutex subscribers and so on... */
Regards,
Mindaugas
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
