Igor, it seems I did a terrible job explaining it. Comments inline!
Am 29.10.2013 um 01:19 schrieb Igor Stasenko <[email protected]>: > 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. I don’t know what gave you the impression it could be that way but it isn’t. There is a component called NetworkService that I’m using to do sends and where I’m registering for incoming messages. I was not talking about the architecture of the application but about ways how to test those setups. For this I have a TestNetworkService that has an instVar otherService. On connection time the NetworkServices set themself via a setter in the other service and a send is done like send: someData otherService doReceive: someData This is the place where I change the execution model for the tests. What would be normally something asynchronous is now synchronous with the mentioned side effect that a send with response will look like A send1 B receive1 B send2 A receive2 A return from receive2 B return from send2 B return from receive1 A return from send1 I really like the tests to be single threaded. It makes debugging a lot easier. So I was evaluating a few possibilities. As long as all of the calls in the above chain are tail calls it should be the same of the calls are nested or not. But that would be a restriction and I’m not sure yet if it is a good one or not. The next approach I do at the moment is that e.g. a send call goes roughly like this p := [ a block for preparing send data ] s := [ a block that sends the data ] s value: p value What I do is to rearrange flow. At the moment where s would be evaluated it is instead made the sender of p and the sender of s will be the former sender of p. So everything that happens in p will return before s is executed. For my execution model this mimicks parallel behaviour. But now the receive/sends are nested and my simple model doesn’t work. I could improve it but it seems like I need to tweak a tweak of a workaround that probably wasn’t the right choice in the first place. What my experience showed me is that often it is a good way to remove a hack instead of hacking a hack. So I’m thinking about if this is the point to let go :) > 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). > As I said the layers are separate. So one idea was to keep it in multiple processes and use semaphores for orchestration. I need to think about that because I don’t have an immediate idea how this should be done. I mean the dispatcher/scheduler does the orchestration of the processes but I would need to make use of this inside a test. Need to think about that. Norbert > > > 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.
