[fpc-devel] Inconsistent use of Timeout in SimpleIPC
dezlov at gmail.com
Tue Jan 5 08:57:42 CET 2016
Did anyone have a chance to review the changes to SimpleIPC?
Patches are attached in the previous message.
Proposed next steps:
1) If everyone is happy - commit changes (should I create a bug report in
2) I can merge "wince" with "win" implementation since they are identical
except for wide types/winapi, but won't be able to test on Windows CE.
3) Investigate if implementations on other platforms can benefit from
message queue and overflow handling.
On 10 December 2015 at 21:02, Denis Kozlov <dezlov at gmail.com> wrote:
> I have rewritten SimpleIPC implementation for Windows.
> Summary of changes:
> 1. Using SetTimer + GetMessage method for handling PeekMessage.
> 2. Store all received incoming messages in a message queue (per IPC
> 3. Implemented message queue (PeekMessage receives messages, ReadMessage
picks from the queue)
> 4. Implemented optional message queue limit and overflow handling (more
on that below).
> 5. Timeout<-1 is forced to -1; Documented meaning of various Timeout
values in comments.
> 6. Minor refactoring and code formatting changes.
> All these changes currently affect only the Windows implementation. The
main IPC interface has not changed. This allows to fix all major issues on
Windows and test the new concept of buffering/queueing IPC messages.
> A new global type was introduced:
>> TIPCMessageOverflowAction = (ipcmoaNone, ipcmoaDiscardOld,
> Added two global variables which configure message queue limit and
overflow handling (affect newly created IPC servers):
>> DefaultIPCMessageOverflowAction: TIPCMessageOverflowAction = ipcmoaNone;
>> DefaultIPCMessageQueueLimit: Integer = 0;
> Currently these are used only in Windows implementation, but they need to
be in the interface section to allow unit testing and perhaps later reuse
on other platforms.
> The second part is a comprehensive test suite for Windows implementation
of SimpleIPC. Tests spawn client mode instances as needed for proper
testing of IPC. Tests check handling of messages, processing delays,
synchronicity and message queue overflow actions. Read comments for each
test routine for additional information. All timing based checks are very
relaxed and can be controlled by IPC_BASETIME constant (a base line time
per message in milliseconds), which can be increased for really-really slow
machines. Simply compile and run. Exception is raised if any errors occur.
> Other platforms will fail most tests due to not implemented featured,
such as message queue and overflow handling. Perhaps it could be added to
FPC test suite for Windows platform only, but I'm not sure how suitable it
is due to complexity of multiple processes and timing checks.
> I also tested separately for compatibility with Lazarus message loop by
using PeekMessage(0, True) in Application.OnIdle, it works perfectly.
> Attached files (full copies included for convenience; patches against FPC
trunk revision 32628 from 10 Dec 2015):
> 1) testipc.pas/testipc.out.txt - tests for SimpleIPC and example output.
> 2) simpleipc.pp/simpleipc.pp.patch - patch and a full copy of main
> 3) simpleipc.inc/simpleipc.inc.patch - patch and a full copy of Windows
include file (not Windows CE).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel