>You did not say which version of Indy you are using. You appear to be using
>Indy 10, which which release of it exactly?
I'm sorry, I forgot to mention. I use Indy 10.1.5
At one point, the threading
>model for TIdDUPServer was changed in Indy 10 from using a single thread to
>manage all Bindings to using multiple threads, one for each Binding
>individually.
This would still mean that the same onudpread event is
triggered right? (with the ABinding parameter set to the current binding)
>That is not how it works.
Please try my example, I must be doing something horribly wrong, because this is exactly how it works in my code.
>Is ShowMessage() still active at the time of the second press?
No.
>For that to happen, the OS would have to be reporting that the first socket
>is not readable until after the second socket has become readable. That is
>not standard socket behavior, so something else has to be happening to block
>the first socket.
I receive no errormessages and I am not blocking the socket in
any other way, the code I sent is 100% all I use.
>ShowMessage() is not thread-safe. Use MessageBox() from the Windows unit
>instead.
ThreadedEvent is set to false, and when I check the stack in
the debugger the event is indeed fired in the main thread, so
that shouldn't be a problem I thought?
To be safe I changed the code to:
procedure TForm64.IdUDPServer1UDPRead(Sender: TObject; AData: TBytes;ABinding: TIdSocketHandle);
var i: Integer;
begin
i := i + 1;
end;
And just placed a breakpoint at "i := i + 1" but the result was exactly the same. I also tried to set threadedevent to false, but again the result was the same.
So in all those cases if I press "send to port 1000" the udpread is fired, but when I press it again nothing happens until I send a packet to port 1001 as well and then udpread is fired twice, once for ABinding.port = 1001 and once for ABinding.port = 1000 (in that LIFO order!)
