[Pharo-dev] Tests with multiple processes
David T. Lewis
lewis at mail.msen.com
Tue Oct 29 14:27:30 EDT 2013
> Am 29.10.2013 um 02:08 schrieb David T. Lewis <lewis at mail.msen.com>:
>> I have some experience with this, not related to Smalltalk but maybe
>> still relevant. I have worked with systems that were designed around
>> networked message passing, implemented on platforms like MS-DOS with
>> slicing kernels, Series I, OS/2, etc. These systems were designed to
>> with asynchronous message passing protocols. The asynchronous designs
>> intended to support primitive OS environments, including MS-DOS with
>> software interrupts for multitasking.
>> These are production-critical manufacturing applications, and in the
>> of modernizing them I have reimplemented the network protocols in Java
>> moved them to new computing platforms. Along the way I have found that
>> asynchronous designs could always be replaced by bidirectional
>> transactions running in the context of a thread or process. Even the
>> that appeared to be most complex have turned out to work perfectly well
>> when modeled as synchronous send-receive transactions on a bidirectional
>> communication channel. The software is much simpler to understand and
>> when structured in this manner.
>> My conclusion is that designing around asynchronous, loosely coupled
>> channels sounds like a good idea, but in practice it leads to
>> complexity, and to systems that are difficult to debug and support.
> I agree. That was the reason for me to look out for a simpler approach. At
> least for testing. Can you elaborate on the bidirectional send-receive
> transaction. Im not sure I understand what happens there. I explained my
> case a bit more in my response to Igor.
I modeled the problem in terms of communication sessions, with message
objects that can be sent and received on a session. By transaction (poor
choice of terms here) I mean an object with an evaluate method that uses a
session to send a message object and receive a response message object,
and that answers an object that encapsulates the result of that completed
transaction (including errors if any).
Early in the project I implemented a kind of session that handled
asynchronous send and receive, keeping track of thread synchronization and
matching response objects to request objects. I expected this to be
necessary for interaction with old MS-DOS and OS/2 based applications that
had been written in that manner, and that were entirely asynchronous and
interrupt driven by design. I practice, I have never actually needed to
use this asynchronous type of processing, because the simple synchronous
session has always been proved sufficient even when interacting with
systems that appeared to be (and were designed to be) completely
asynchronous and event driven.
More information about the Pharo-dev