Am 29.10.2013 um 02:08 schrieb David T. Lewis <le...@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 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. > 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“. I’m not sure I understand what happens there. I explained my case a bit more in my response to Igor. thanks, Norbert > $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 <norb...@hartl.name> wrote: >> >>> >>> Am 28.10.2013 um 23:50 schrieb Norbert Hartl <norb...@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. >
