Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 03.10.2015 19:21, Tomas Hajny wrote:

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently searching for a
file FindFirst without any sleep in between. Maybe related to
PeekRequest calls?
The solution is simple and is only a problem of the demo application 
(not advancedipc.pp code). Just add an "ELSE SLEEP(XYZ)" block into the 
server while-loop.


Ondrej
program TestIPC_Server;

{$MODE ObjFPC}{$H+}

uses
  Classes, SysUtils, AdvancedIPC;

const
  STRINGMESSAGE_WANTS_RESPONSE = 3;
  STRINGMESSAGE_NO_RESPONSE = 2;
  MESSAGE_STOP = 4;

var
  xServer: TIPCServer;
  xStream, xResponseStream: TStringStream;
  xMsgID: Integer;
  xMsgType: TMessageType;
  xNotRunningMessagesCount: Integer;
begin
  xServer := nil;
  xStream := nil;
  xResponseStream := nil;
  try
xStream := TStringStream.Create('');
xResponseStream := TStringStream.Create('OK');

//first get all messages from the hello server
xServer := TIPCServer.Create(nil);
xServer.ServerID := 'hello';
xServer.StartServer;

WriteLn('Server ', xServer.ServerID, ' started.');
WriteLn('-');

while True do
begin
  if xServer.PeekRequest(xMsgID{%H-}, xMsgType{%H-}) then
  begin
case xMsgType of
  STRINGMESSAGE_WANTS_RESPONSE, STRINGMESSAGE_NO_RESPONSE:
  begin
xServer.ReadRequest(xMsgID, xStream);
WriteLn('Received string message:');
WriteLn(xStream.DataString);
if xMsgType = STRINGMESSAGE_WANTS_RESPONSE then
begin
  xResponseStream.Position := 0;
  xServer.PostResponse(xMsgID, STRINGMESSAGE_NO_RESPONSE, 
xResponseStream);
  WriteLn('Posting response.');
end;
WriteLn('-');
  end;
  MESSAGE_STOP:
  begin
WriteLn('Stopping '+xServer.ServerID+' server.');
WriteLn('-');
Break;
  end;
end;
  end else
Sleep(50);
end;

FreeAndNil(xServer);

//now try to get all unhandled messages from the not_running server
//please see that the messages are not peeked in the order they have been 
posted (this is correct/designed behavior).
xServer := TIPCServer.Create(nil);
xServer.ServerID := 'not_running';
xServer.StartServer(False);

WriteLn('');
WriteLn('Server ', xServer.ServerID, ' started.');
WriteLn('-');

xNotRunningMessagesCount := 0;
while xServer.PeekRequest(xStream, xMsgID, xMsgType) do
begin
  if xMsgType = STRINGMESSAGE_NO_RESPONSE then
  begin
WriteLn('Received message: ', xStream.DataString);
Inc(xNotRunningMessagesCount);
  end else
WriteLn('ERROR: Wrong message type: ', xMsgType);

  WriteLn('-');
end;

if xNotRunningMessagesCount <> 10 then
begin
  WriteLn('ERROR: Wrong message count: ', xNotRunningMessagesCount);
  WriteLn('-');
end;

WriteLn('Stopping '+xServer.ServerID+' server.');
WriteLn('-');
FreeAndNil(xServer);
  finally
xServer.Free;
xStream.Free;
xResponseStream.Free;
  end;
end.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 03.10.2015 19:21, Tomas Hajny wrote:

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently searching for a
file FindFirst without any sleep in between. Maybe related to
PeekRequest calls? Second, I noticed that unlike the "simple" test,
the "advanced" leaves a temporary file 'hello--t' in the
temporary directory after finishing.
First - Yes that's true, I didn't add any sleep into the code for 
testing purposes.

Second - I'll check that!


Apart from that, I replaced the hard-coded '*' with a reference to
AllFilesMask constant defined in unit System, because some of FPC
targets need a different mask when searching for all files (that is
not the case of OS/2, but e.g. GO32v2 would need that if not running
on a LFN enabled system) - committed in svn trunk.



Thanks! I found some smaller bugs that I send over to the temporary copy 
in Lazarus trunk. I'll sync both files and send patches back.


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 03.10.2015 19:21, Tomas Hajny wrote:

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently searching for a
file FindFirst without any sleep in between. Maybe related to
PeekRequest calls? Second, I noticed that unlike the "simple" test,
the "advanced" leaves a temporary file 'hello--t' in the
temporary directory after finishing.

Apart from that, I replaced the hard-coded '*' with a reference to
AllFilesMask constant defined in unit System, because some of FPC
targets need a different mask when searching for all files (that is
not the case of OS/2, but e.g. GO32v2 would need that if not running
on a LFN enabled system) - committed in svn trunk.



Attached patched for FPC and Lazarus to sync advancedipc.pp. The current 
version in FPC trunk is out-dated (the Lazarus trunk version just misses 
the AllFilesMask constant).


I could not reproduce the "temporary file 'hello--t' was not 
deleted" problem. Actually all files should be deleted in 
StopServer(True) or Free -> DeletePendingRequests.


What demo did you observe the problem in? TestIPC_Server/TestIPC_Client?

Ondrej
Index: packages/fcl-base/src/advancedipc.pp
===
--- packages/fcl-base/src/advancedipc.pp(revision 31926)
+++ packages/fcl-base/src/advancedipc.pp(working copy)
@@ -30,7 +30,11 @@
   {$IFDEF UNIX}
   baseunix,
   {$endif}
-  sysutils, Classes;
+  sysutils, Classes
+  {$IF FPC_FULLVERSION<20701}
+  ,LazUTF8SysUtils
+  {$ENDIF}
+  ;
 
 const
   HEADER_VERSION = 2;
@@ -60,13 +64,14 @@
 FMessageVersion: Integer;
   protected
 class function ServerIDToFileName(const aServerID: string; const aGlobal: 
Boolean): string;
-function GetResponseFileName(const aMsgID: Integer): string;
+function GetResponseFileName(const aRequestID: Integer): string;
 function GetResponseFileName(const aRequestFileName: string): string;
-function GetPeekedRequestFileName(const aMsgID: Integer): string;
+function GetPeekedRequestFileName(const aRequestID: Integer): string;
 function GetPeekedRequestFileName(const aRequestFileName: string): string;
 function GetRequestPrefix: string;
-function GetRequestFileName(const aMsgID: Integer): string;
-function RequestFileNameToMsgID(const aFileName: string): Integer;
+function GetRequestFileName(const aRequestID: Integer): string;
+function RequestFileNameToID(const aFileName: string): Integer;
+function RequestExists(const aRequestFileName: string): Boolean;
 
 function GetUniqueRequest(out outFileName: string): Integer;
 procedure SetServerID(const aServerID: string); virtual;
@@ -122,19 +127,19 @@
   public
 //peek request and read the message into a stream
 function PeekRequest(const aStream: TStream; out outMsgType: 
TMessageType): Boolean; overload;
-function PeekRequest(const aStream: TStream; out outMsgID: Integer; out 
outMsgType: TMessageType): Boolean; overload;
-function PeekRequest(const aStream: TStream; out outMsgID: Integer; out 
outMsgType: TMessageType; const aTimeOut: Integer): Boolean; overload;
+function PeekRequest(const aStream: TStream; out outRequestID: Integer; 
out outMsgType: TMessageType): Boolean; overload;
+function PeekRequest(const aStream: TStream; out outRequestID: Integer; 
out outMsgType: TMessageType; const aTimeOut: Integer): Boolean; overload;
 //only peek request, you have to read/delete the request manually with 
ReadRequest/DeleteRequest
 function PeekRequest(out outMsgType: TMessageType): Boolean; overload;
-function PeekRequest(out outMsgID: Integer; out outMsgType: TMessageType): 
Boolean; overload;
-function PeekRequest(out outMsgID: Integer; out outMsgType: TMessageType; 
const aTimeOut: Integer): Boolean; overload;
+function PeekRequest(out outRequestID: Integer; out outMsgType: 
TMessageType): Boolean; overload;
+function PeekRequest(out outRequestID: Integer; out outMsgType: 
TMessageType; const aTimeOut: Integer): Boolean; overload;
 //read a peeked request (that hasn't been read yet)
-function ReadRequest(const aMsgID: Integer; const aStream: TStream): 
Boolean;
+function ReadRequest(const aRequestID: Integer; const aStream: TStream): 
Boolean;
 //delete a peeked request (that hasn't been read yet)
-procedure DeleteRequest(const aMsgID: Integer);
+procedure DeleteRequest(const aRequestID: Integer);
 
 //post response to a request
-procedure PostResponse(const aMsgID: Integer; const aMsgType: 
TMessageType; const aStream: TStream);
+procedure PostResponse(const aRequestID: Integer; const aMsgType: 
TMessageType; const aStream: TStream);
 
 //find the highest request ID from all pending requests
 function FindHighestPendingRequestId: 

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On 21 Sep 15, at 14:03, Ondrej Pokorny wrote:
 .
 .
> Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
> 
> I prepared a fully compatible AdvancedIPC unit. See the attachment.
> There is a unit mysimpleipc.pp that should replace the simpleipc.pp in 
> FPC sources. I renamed it in order to prevent file name problems and to 
> be able to check the compatibility without recompiling FPC sources 
> (basically just use "mysimpleipc" in the uses instead of "simpleipc").
 .
 .

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced" 
test programs work, well done! I noticed two issues when running the 
"advanced" tests, though. First, the server increases the CPU 
considerably. There seems to be a loop permanently searching for a 
file FindFirst without any sleep in between. Maybe related to 
PeekRequest calls? Second, I noticed that unlike the "simple" test, 
the "advanced" leaves a temporary file 'hello--t' in the 
temporary directory after finishing.

Apart from that, I replaced the hard-coded '*' with a reference to 
AllFilesMask constant defined in unit System, because some of FPC 
targets need a different mask when searching for all files (that is 
not the case of OS/2, but e.g. GO32v2 would need that if not running 
on a LFN enabled system) - committed in svn trunk.

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On Sat, October 3, 2015 19:59, Ondrej Pokorny wrote:
> On 03.10.2015 19:21, Tomas Hajny wrote:
>> Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
>> test programs work, well done! I noticed two issues when running the
>> "advanced" tests, though. First, the server increases the CPU
>> considerably. There seems to be a loop permanently searching for a
>> file FindFirst without any sleep in between. Maybe related to
>> PeekRequest calls?
> The solution is simple and is only a problem of the demo application
> (not advancedipc.pp code). Just add an "ELSE SLEEP(XYZ)" block into the
> server while-loop.

Yes, indeed, that fixed it, thanks. I've added the test / example to FPC
SVN under the directory examples.

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On Sat, October 3, 2015 19:54, Ondrej Pokorny wrote:
> On 03.10.2015 19:21, Tomas Hajny wrote:
 .
 .
> Attached patched for FPC and Lazarus to sync advancedipc.pp. The current
> version in FPC trunk is out-dated (the Lazarus trunk version just misses
> the AllFilesMask constant).

Thanks, I applied a modified version of your patch to FPC SVN; since we
put the file to FPC trunk, the modifications related to support of FPC
2.6.4 would be superfluous there and I skipped them.


> I could not reproduce the "temporary file 'hello--t' was not
> deleted" problem. Actually all files should be deleted in
> StopServer(True) or Free -> DeletePendingRequests.
>
> What demo did you observe the problem in? TestIPC_Server/TestIPC_Client?

Yes. I cannot reproduce it either, though. I guess that it must have
resulted from me killing the server at some point (due to the high CPU
load), i.e. apparently a false alarm - sorry. :-(

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel