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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
