Using WaitForSingleObject in DataReceived event

[Ecole7]

Hello,

I'd like to know if using the WaitForSingleObject() function in an RtcDataProvider DataReceived event can cause problems. Note that I used the mode "multithreaded".

R: = WaitForSingleObject (vbpid, 100);

This function is used to verify an external process written in Visual Basic. It allows me to check if this application is running.

Thank you in advance for your answer.

Vincent

[D.Tkalcec (RTC)]

Since the WaitForSingleObject API is blocking and does NOT process Windows messages while waiting, provided your Server is Multi-Threaded and there are enough threads available in the RTC Thread pool for other things that should continue working while that thread is waiting, your main concern should be the total time you spend in that event, because (A) you are blocking a thread and (B) your connection could get lost or dropped while waiting, in which case the Server would be unable to send a response back to the Client. Other than that, I don't see any problems with using the WaitForSingleObject API from inside RTC events to wait for external signals.

Best Regards,
Danijel Tkalcec

[Ecole7]

Hello,

Thank you for the clarification.

Here are the changes I made to my code:
 
Function WaitForStatus: Boolean;
var
  tm: Integer;
begin
  Tm: = 100; // 1sec timeout
  With AppEcole [_ixa] do begin
   While (Tm> 0) do begin
    If State = VBEV_READY then begin
     Result: = True;
     Exit;
    end;
    Application.ProcessMessages;
    Sleep (10);
    Dec (tm);
   end;
  end;
  Result: = False;
end;

...
// check if the VB application has closed
R: = WaitForSingleObject (vbpid, 0); // no timeout!
If R <> WAIT_TIMEOUT then begin
  ...
End else if WaitForStatus then begin // read the status of the application
  ...
end;
...

The State variable is linked to the VB application (OLE automation)

For now, the tests are OK.
Is this code more compatible with the operation of the RTC components?

Thank you in advance for your answer.

Vincent

[D.Tkalcec (RTC)]

It looks like there was a missunderstanding. I've said that using WaitForSingleObject is OK, because it is a blocking call which does NOT process Windows Messages. But ... the Application.ProcessMessages or any other API or method which DOES PROCESS Windows Messages should NEVER be called from any event triggered by RTC components.

There is a Quick-Start Topic about this.

Best Regards,
Danijel Tkalcec

[Ecole7]

OK,
But In my case I just had to monitor a variable for a given time. Is using RtcWaitFor possible?
The goal is to respond to an HTTP request with a certain delay that depends on an external application.

[D.Tkalcec (RTC)]

Waiting inside RTC events is OK. Responding to Requests with a Delay is also OK. You will (obviously) be blocking a thread while waiting and might also end up with a closed connection if you wait too long, but that's something you should always take into account.

Processing Windows Messages while waiting inside RTC events is NOT OK. Because the RtcWaitFor function is designed to process Windows Messages and to execute events "synchronized with the Main Thread" by using the Sync method, it may ONLY be called directly from the Main Thread and NEVER from inside any events triggered by RTC components or code executed as a result of an event triggered by a RTC component.

[Ecole7]

Hello,

Thank you for your patience. I think I understood ...

1. Do not use Application.ProcessMessages in RTC components (threads) events.

2. It is possible to pause the event (thread) by the sleep () function,
but avoid having too many threads paused (check the value of RtcTotalThreadsBusy and react accordingly).

3. Use WebSockets (asychronous query) instead of HTTP (POST or GET).

[D.Tkalcec (RTC)]

Whether you are going to use WebSockets or the usual request/response scheme over HTTP/S depends on your personal preferences and Application requirements. Both have positive and negative sides. But your other 2 points are correct.

Best Regards,
Danijel Tkalcec

[Ecole7]

Thank you for your reply,
For my application that worked in AJAX, the WEBSocket is useful because it allows to realize asynchronous requests, thus to avoid unnecessarily blocking threads to wait for a response.
Greetings
Vincent