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 time slicing kernels, Series I, OS/2, etc. These systems were designed to operate with asynchronous message passing protocols. The asynchronous designs were intended to support primitive OS environments, including MS-DOS with software interrupts for multitasking.
These are production-critical manufacturing applications, and in the course of modernizing them I have reimplemented the network protocols in Java and moved them to new computing platforms. Along the way I have found that the asynchronous designs could always be replaced by bidirectional send-receive transactions running in the context of a thread or process. Even the systems 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 debug 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 unnecessary complexity, and to systems that are difficult to debug and support. $0.02 Dave On Tue, Oct 29, 2013 at 01:19:17AM +0100, Igor Stasenko wrote: > Maybe i'm off track, but here my thoughts: > > - one big misconception (and most problems which arising from it), that > people tend to use a bidirectional communication models instead of > unidirectional. > In bidirectional you tend to think as if you using same channel for sending > and receiving data. > The truth is, that it is two unidirectional channels, wired in the way so > they look like single bidirectional channel. > > And what it means, that coupling sending and receiving activities in a > single thread is wrong: > - you should not wait for data only if you sent something > - you should not expect that activity from other end is possible only > after you _send_ something. > > If you treat connection as two unidirectional, loosely coupled channels, > instead of single bidirectional one, > you will find that in such setup you don't have many problems. > > You should definitely go for (2), e.g. you should decouple a > transport/communication layer > from your program/logic flow: if some process wants to send data and block > until some response to > that message arrived, you should do so. > You can simply put that process on semaphore, and adding it to the list of > 'awaiting answer' > processes in your scheduler which runs in separate process to handle > incoming data. > Then you can have different strategies, what to do if > a) data seems taking too long to arrive (signal timeout) > b) connection lost > c) etc.. > > ohh.. with smalltalk it is so easy to operate with those things (the fact > the VM is green-threaded doesn't > changes much). > > > > On 28 October 2013 23:52, Norbert Hartl <[email protected]> wrote: > > > > > Am 28.10.2013 um 23:50 schrieb Norbert Hartl <[email protected]>: > > > > Are there any approaches to simulate coroutines in a single thread > > environment or approaches to deal with multiple processes within one > > process? > > > > > > That should have been > > > > Are there any approaches to simulate coroutines in a single thread > > environment or approaches to deal with multiple processes within one test? > > > > Norbert > > > > > > -- > Best regards, > Igor Stasenko.
