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 <norbert@hartl.name> wrote:
Am 28.10.2013 um 23:50 schrieb Norbert Hartl <norbert@hartl.name>:
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.