RE: (forte-users) Confusion with return event

Question

Samer,
The return event is delivered to the calling task, which is the window in
your first test. It is not deliverd to the event loop of the service object
unless the call to the processor originated in the event loop, which is the
case in your second test. The output you get from the server is exactly as I
would expect.
You need the following code in you client:
event loop
postregister
SomeService1.StartImmediate();
when SomeService1.Proc.ProcessEvent_return do
task.Part.Logmgr.Putline('ProcessEvents_return');
when SomeService1.Proc.ProcessEvent_exception do
task.Part.Logmgr.Putline('ProcessEvents_exception');
end event;
Note that this logoutput will not be written to a logfile, but will appear
in the logwindow which is opened when you start a client application.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. [phone]
Fax. [phone]
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. [phone]
Fax. [phone]
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Samer Kanjo [mailto:skanjoyahoo.com]
Sent: Thursday, January 18, 2001 1:54 AM
To: ForteUsers
Subject: (forte-users) Confusion with return event
I have observed some odd behavior when attempting to
catch a return event for a method invoked using start
task. I provided the primary classes I used during my
test and some output produced by those classes at the
bottom of this message.
The SomeService1 class is used to create an
environment visible service object and the Processor
class is one of its members. The Processor class
starts processing when one of two things happens: the
SomeService1 timer ticks off 10 seconds or when
SomeService1.StartImmediate is called directly by
another entity. Either way StartImmediate is called to
start processing.
The provided output is the result of starting a test
application and invoking StartImmediate from another
object (I used a window) and then observing what
happens when the timer ticks. As you can see the
invocation from the window did not result in the
return event being received. However, the return event
was received when the timer ticked.
According to the Forte documentation a return event
will only be posted to the parent task's event queue.
Since I am making a cross partition call, the window
and service object are not really in the same task
(Unless my assumption is wrong). That would explain
why the window did not cause a return event to be
generated but was an event generated but not caught
and if so where did the event go?
In SomeService2 class I added an event StartProcessing
and moved the code from StartImmediate to the
StartProcessing event case in the event loop and
simply posted the StartProcessing event in
StartImmediate. I performed the same test I used when
testing SomeService1. The Traceback output is
identical for the window invocation but the return
event is received this time! Why?
It seems that to guarantee the receipt of a return
event an asynchronous task must be initiated from
within an event loop. Is this correct?
I do not understand this behavior does someone have
any thoughts on this? How can you guarantee the
receipt of a return event?
Samer Kanjo
OUTPUT FROM SOMESERVICE1
StartTaskTest_cl0: processing loop listening
StartTaskTest_cl0:
Traceback:
SomeService.StartImmediate at line 1
TestWin.Display at line 4
C++ Method(s)
UserApp.Run at offset 105
StartTaskTest_cl0:
StartTaskTest_cl0: Start processing...
StartTaskTest_cl0: Processing complete.
StartTaskTest_cl0:
Traceback:
SomeService.StartImmediate at line 1
SomeService.ProcessingLoop at line 9
StartTaskTest_cl0:
StartTaskTest_cl0: Start processing...
StartTaskTest_cl0: Processing complete.
StartTaskTest_cl0: ProcessEvents_return
OUTPUT FROM SOMESERVICE2
StartTaskTest_cl0: processing loop listening
StartTaskTest_cl0:
Traceback:
SomeService2.StartImmediate at line 1
TestWin.Display at line 4
C++ Method(s)
UserApp.Run at offset 105
StartTaskTest_cl0:
StartTaskTest_cl0: Start processing...
StartTaskTest_cl0: Processing complete.
StartTaskTest_cl0: ProcessEvents_return
StartTaskTest_cl0:
Traceback:
SomeService2.StartImmediate at line 1
SomeService2.ProcessingLoop at line 9
StartTaskTest_cl0:
StartTaskTest_cl0: Start processing...
StartTaskTest_cl0: Processing complete.
StartTaskTest_cl0: ProcessEvents_return
SOMESERVICE1 CLASS
begin CLASS;
class SomeService1 inherits from Framework.Object
has public attribute proc: StartTaskTest.Processor;
has public attribute processing: Framework.boolean;
has public method Init;
has public method ProcessingLoop;
has public method StartImmediate;
has property
shared=(allow=off, override=on);
transactional=(allow=off, override=on);
monitored=(allow=off, override=on);
distributed=(allow=on, override=on, default=off);
end class;
method SomeService1.Init
begin
super.Init();
processing = FALSE;
proc = new;
start task ProcessingLoop();
end method;
method SomeService1.ProcessingLoop
begin
timer : Timer = new;
timer.tickInterval = 10000;
event loop
task.part.logmgr.putline('processing loop
listening');
timer.isActive = TRUE;
when timer.tick do
StartImmediate();
when proc.ProcessEvents_return do
task.part.logmgr.putline('ProcessEvents_return');
processing = FALSE;
when proc.ProcessEvents_exception do
task.part.logmgr.putline('ProcessEvents_exception');
processing = FALSE;
when task.shutdown do
exit;
end event;
end method;
method SomeService1.StartImmediate
begin
task.part.logmgr.putline(task.traceBack());
processing = TRUE;
start task proc.ProcessEvents() where completion =
event;
end method;
end CLASS;
SOMESERVICE2 CLASS
begin CLASS;
class SomeService2 inherits from Framework.Object
has public attribute proc: StartTaskTest.Processor;
has public attribute processing: Framework.boolean;
has public event StartProcessing;
has public method Init;
has public method ProcessingLoop;
has public method StartImmediate;
has property
shared=(allow=off, override=on);
transactional=(allow=off, override=on);
monitored=(allow=off, override=on);
distributed=(allow=on, override=on, default=off);
end class;
method SomeService2.Init
begin
super.Init();
processing = FALSE;
proc = new;
start task ProcessingLoop();
end method;
method SomeService2.ProcessingLoop
begin
timer : Timer = new;
timer.tickInterval = 10000;
event loop
task.part.logmgr.putline('processing loop
listening');
timer.isActive = TRUE;
when timer.tick do
StartImmediate();
when self.StartProcessing do
processing = TRUE;
start task proc.ProcessEvents() where completion =
event;
when proc.ProcessEvents_return do
task.part.logmgr.putline('ProcessEvents_return');
processing = FALSE;
when proc.ProcessEvents_exception do
task.part.logmgr.putline('ProcessEvents_exception');
processing = FALSE;
when task.shutdown do
exit;
end event;
end method;
method SomeService2.StartImmediate
begin
task.part.logmgr.putline(task.traceBack());
post StartProcessing;
end method;
end CLASS;
PROCESSOR CLASS
begin CLASS;
class Processor inherits from Framework.Object
has public method Init;
has public method ProcessEvents where completion =
(return = ProcessEvents_return, exception =
ProcessEvents_exception);
has property
shared=(allow=off, override=on);
transactional=(allow=off, override=on);
monitored=(allow=off, override=on);
distributed=(allow=off, override=on);
end class;
method Processor.Init
begin
super.Init();
end method;
method Processor.ProcessEvents
begin
task.part.logmgr.putline('Start processing...');
task.Delay(msecs = 1500);
task.part.logmgr.putline('Processing complete.');
end method;
end CLASS;
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Answer 1

Yes, you're right. The return event is queued until the moment that you
actually enter an eventloop. I stand corrected.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. [phone]
Fax. [phone]
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. [phone]
Fax. [phone]
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Thursday, January 18, 2001 6:13 PM
To: Rottier, Pascal
Cc: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users) Confusion with return event
I think it is always safe to use start task with where complition = event
clause before event loop. The reason is described in Forte Help in the
Complition Clause index:
"Requesting the return and exception events automatically registers the
events for the calling task. When the asynchronous method completes or
terminates, Forté adds the appropriate event to the calling task's event
queue.
This registration is unlike the event registration for the event statement.
In the event statement, the event is registered just before the event
statement is ready to process the event. In the start task statement, the
return and exception events are registered when the task is started, even
though it can be much later on that your application is prepared to wait for
those events. Therefore, only the "parent" task that executes the start task
statement is registered for the completion event of the started task."
and some comments from "Forte Performance and Patterns" page 18:
"When you use the where completion = event clause in the start task
statement, Forte automatically buffer the return event until you register
for it. Therefore, you do not need to worry about the child task completing
before you register for its return event".
Regards,
Zenon
-----Original Message-----
From: Rottier, Pascal [SMTP:Rottier.Pascalpmintl.ch]
Sent: Thursday, January 18, 2001 11:16 AM
To: 'Samer Kanjo'; ForteUsers
Subject: RE: (forte-users) Confusion with return event
Yes, if you want the eventloop of the service object to be informed when
the
method on the processor class is invoked, regardless of who invoked it,
then
you should simply post an event as the last statement inside the method on
the processor class.
The return events are only used to inform a partent task that a child-task
has completed. So, only the calling task receives the event, only if the
calling task is inside an event-loop at the moment the child-task
terminates
and only if there really is a child task (method started using "start task
Note, that the calling task doesn't have to be inside an event loop when
the
asynchronous call is made. It has to be inside an eventloop when the
asynchronous task terminates. The following piece of code works just as
well:
SomeService1.StartImmediate();
self.DoSomeOtherStuff();
event loop
when SomeService1.Proc.ProcessEvent_return do
task.Part.Logmgr.Putline('ProcessEvents_return');
when SomeService1.Proc.ProcessEvent_exception do
task.Part.Logmgr.Putline('ProcessEvents_exception');
end event;
However, if the asynchronous task started from within "StartImmediate"
finishes before the client gets a chance to enter its event loop, then
you're too late to catch the event. That's why it's safer to use the
"postregister" function, which makes sure a certain action is not started
untill all events from the event loop have been registered.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. [phone]
Fax. [phone]
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. [phone]
Fax. [phone]
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Samer Kanjo [mailto:skanjoyahoo.com]
Sent: Thursday, January 18, 2001 5:04 PM
To: ForteUsers
Subject: RE: (forte-users) Confusion with return event
Pascal,
So you are confirming that a return event can only be
received in an event loop if a task is started from
within that event loop.
After making your proposed changes I was able to
receive the return event in the window.
I originally wanted the SomeService event loop to
always receive the return event regardless of whether
or not StartImmediate is called by some other entity
or called when the timer ticks. It seems that the only
way to do this is with events. Is that correct?
Thank you for insight,
Samer Kanjo
--- "Rottier, Pascal" <Rottier.Pascalpmintl.ch>
wrote:
Samer,
The return event is delivered to the calling task,
which is the window in
your first test. It is not deliverd to the event
loop of the service object
unless the call to the processor originated in the
event loop, which is the
case in your second test. The output you get from
the server is exactly as I
would expect.
You need the following code in you client:
event loop
postregister
SomeService1.StartImmediate();
when SomeService1.Proc.ProcessEvent_return do
task.Part.Logmgr.Putline('ProcessEvents_return');
when SomeService1.Proc.ProcessEvent_exception do
task.Part.Logmgr.Putline('ProcessEvents_exception');
end event;
Note that this logoutput will not be written to a
logfile, but will appear
in the logwindow which is opened when you start a
client application.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. [phone]
Fax. [phone]
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. [phone]
Fax. [phone]
E-mail: Rottier.Pascalpmintl.ch--
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com