On Mon, 27 Sep 2010, Brian Hays wrote:
Hi Brian,
> I made a discovery regarding this nagging error that has been
> reported occasionally during Indexing operations.
> We found this out because we made a subtle change to our app's
> statusbar display of today's date. All we did is make a call to
> __SetCentury(.t.), and the ADS 6619 error started occurring
> intermittently during indexing.
>
> xHarbour provides a "Listener" feature that forwards
> *SETTINGS* that need to stay in sync with ADS. Consider the following
> standard calls to Set():
> case HB_SET_DATEFORMAT :
> case HB_SET_DEFAULT :
> case HB_SET_DELETED :
> case HB_SET_EPOCH :
> case HB_SET_EXACT :
> case HB_SET_PATH :
> case HB_SET_DECIMALS :
>
> Most of these - especially SET_DATEFORMAT - are not immediately
> considered "database calls". In my case, __SetCentury() is considered
> purely a UI function. BUT internally it calls Set(HB_SET_DATEFORMAT),
> and this then produces a call to AdsSetDateFormat(), which produces the
> 6619 error if it occurs while a callback is being processed.
> To sum it up:
> Any call that changes any of the above settings, directly or indirectly,
> will call an ACE32 function that will throw error 6619 if a callback
> is being processed.
> It was all the more hidden because this call is done on our main window
> refresh to show the date and time on the statusbar-not by any data
> processing code or even the actual callback handler for the
> Indexing Progress display. But if it happens in the split second while
> we receive the callback and paint the meter, the error occurs.
> I need to spend some more time on this to determine what to do
> so it's not a lurking problem for everyone.
> Basically, there are a LOT of standard calls that are not safe to
> be using while you've registered an ADS callback for indexing or
> packing, etc. But it's not quite safe to turn off the Listener because
> these settings do need to stay in sync..
The problem is much deeper.
First I would like toi say that I was never fun of this automatic
"Listener" which can forwards settings to other subsystems.
Just simply it can kill the performance if such simply Clipper
code is used:
func DToAnsi( dt )
local cDT, cDF := set( _SET_DATEFORMAT, "YYYY.MM.DD" )
cDT := DToC( dt )
set( _SET_DATEFORMAT, cDF )
return cDT
I know few programs using such functions to format thousands of
date values in reports or browsers and you can imagine what happens
with them when callback functions produce to big overhead.
So the first very serious problem is performance.
The second one is reentrant and concurrent access to ADS engine.
In your case using call back function exploited the problem showing
that it's not reentrant safe.
But we have exactly the same problem in MT mode.
Harbour has fully functional MT mode with automatic thread
synchronization to the item write level. Each thread uses
its own SETs so functions like above DToAnsi() are MT safe
in Harbour. Unfortunately the SET call back mechanism used
by ADS RDD is not MT safe and breaks it. So working on MT
mode in Harbour I decided that only main thread will set
this call back so only SET changes in main thread are forwarded
to ADS engine. It's a hack but at least it make ADS usable
in MT programs.
In summary if you ask me about it then I have nothing against
full removing automatic SET forwarding from ADS engine.
Of course I know that it's not easy move after such many years
when people used to live with it and many programs depends on
this feature.
I'm not ADS user so such decision I'm leaving to you and other
real ADS users.
best regards,
Przemek
ps. I'm setting CC to Harbour and xHarbour devel lists.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
