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.
