Devart Forums

Hi there

I was playing around with the TOraAlerter Demo and stumbled across a Busywait Problem for which I have several questions. The situation is basically as follows. An application tries to trigger another one to do a reload. The app does this using the ora-alerter and the reload is done using oraqueries in the OnEvent of the corresponding receiving alerter.

So, one has Apps A & B, where A notifies B, and B does executes several oraqueries in the OnEvent-Handler.

What I have noticed is that it takes quite a bit longer if the reload is executed from within the event than it takes if it is executed later (outside the event). I presume the reason for this is the following code in the TExecThread class:

procedure TExecThread.Execute;
var
hExecThread: IntPtr;
begin
hExecThread := AllocGCHandle(Self, False);
try
try
TRunMethod(FMethodDesc.RunMethod);
FException := nil;
PostMessage(FMethodDesc.hWindow, WM_ENDTHREAD, DWORD(Integer(hExecThread)), 0);
while not Terminated do; <= BUSYWAIT HERE SLOWING APP B DOWN
except .....

The questions I have are:
- Is this done this way by design?
- If so, why?
- Why not put a sleep in there (for instance)?
- Is the TOraAlerter.OnEvent not expected to do "large" updates?
(In which case I'll just change my code.)

Thanks for any insight on this. I am by no means an alerting or threading
expert, so I am thankful for any clues that may enlighten me )

cheerio
christophe

We have fixed this problem. In the next build of ODAC we'll remove the loop from the TExecThread.Execute procedure.

We are currently using the described architecture in our application in a so-called "stable release". Hence, we'd like to fix the issue yet we'd like to avoid a general ODAC update. By your reply I assume the fix is not a big deal and quite local in the code. If so, could I get the patch for that?

thanks for your help, cheerio
christophe

Please contact me by e-mail olegp*devart*com and specify your license number.

Ok did that...