[fpc-devel] Inconsistent use of Timeout in SimpleIPC

[Michael Van Canneyt]

On Sun, 6 Dec 2015, Denis Kozlov wrote:

> I got the Plan B working (SetTimer+GetMessage) for SimpleIPC.
>
> However, it is not possible at all to get TSimpleIPCServer.PeekMessage to NOT 
> read the message, i.e. to respect DoReadMessage=False parameter.
>
> The only way to make TSimpleIPCServer.PeekMessage respect DoReadMessage=False 
> parameter is to store locally all sent data streams and then feed them to 
> user on ReadMessage call. Meanwhile, TSimpleIPCServer.PeekMessage with 
> DoReadMessage=True can loop trough ReadMessage call until there are no more 
> buffered messages left.
>
> There is a concern that locally buffered data streams will keep growing if 
> server stops processing them while clients keep sending them. We can either 
> (A) delegate this concern to the user of the IPC server, or (B) hard code 
> some limit on the maximum number of buffered data streams. Any 
> recommendations?

In fact, to address some other issues in simpleipc, my plan was to do just that for all platforms:
keep all messages in a linked list or queue, so that peek message can just check in the list, and 
if it is empty, try to get the next message.

So please go ahead and implement this. I wanted to introduce a property MaxMessageBufferSize
which keeps the maximum amount of messages that can be held in memory, and if more messages 
arrive, discard old messages. (or introduce a enumerated property that tells the class what todo
TBufferOverFlowAction = (baDiscardOld,baDiscardNew,baError)

>
> There are alternative IPC mechanisms available in Windows (Pipes, Sockets, 
> DDE, etc), but that might be like opening another can of worms. I'm still 
> confident that we can get a fully functioning IPC going using WM_COPYDATA, it 
> just might get a bit more complicated.

Well, WM_COPYDATA is - under normal circumstances - the most efficient mechanism.

Michael.