These are chat archives for petabridge/akka-bootcamp

4th
May 2015
varghesep
@varghesep
May 04 2015 11:47
I'm going through your boot camp and finished the Lesson 1.2. The 1 Million dollar question that I have is why do we do this way with a read actor and a write actor and not as a single while loop in the Main method in the program.cs (without actors and without many lines of code). Is the benefit that we get out of this type of architecture is the efficient use of the threads? Thanks for the guidance.
Maximusya
@Maximusya
May 04 2015 11:51
@varghesep same thoughts visited me through the whole first unit. The lessons do not teach HOW to do things one way or another. They are just to introduce Actors to you. So bear with architecture and design shortcomings, pat yourself on the head for seeing the shortcomings - and just move on.
Or suggest a solid intro-unit yourself :)
Roger Johansson
@rogeralsing
May 04 2015 12:08
I'm on the Akka.NET team, not Petabridge so I dont know exactly why they did it this way, but a good guess is: since actors process one message at a time, it is a good fit for the console writer, so that the actor can set text colors and write messages w/o interference from other parties. regarding the read side, this is probably just to make the user get the hang of actors and how they work. and not so much related to perf or efficiency
having multithreaded code write to the console can yield strange outputs where colors and lines are mixed up
Ralf Westphal
@ralfw
May 04 2015 16:22
I wonder what’s wrong with this: https://gist.github.com/ralfw/8b5e796f5012f549b170 The HeadActor „owns“ a form. When the form throws an event the HeadActor tells a BodyActor what to do. The BodyActor sends back a message to its sender - which should be the HeadActor. But: the HeadActor never receives a message back from the BodyActor. Strange. Any ideas?
Roger Johansson
@rogeralsing
May 04 2015 16:28
Hmmm you create the head actor before Application.Run, so I dont think there is an active synchronization context at that point. not sure, but that would be my guess
as the head actor is configured to use the current sync context dispatcher
Ralf Westphal
@ralfw
May 04 2015 16:32
no, i think the syc ctx is available after the first form has been instanciated.
no code can be run after application.run() it’s blocking.
calling Tell() on headActor before App.Run() works.
but at least your theory explains why using the syn dispatcher before creating a form does not work :-)
Roger Johansson
@rogeralsing
May 04 2015 16:40
I found the problem :)
            dlg.textBox1.KeyUp += (e,s) =>
            {
                var msg = dlg.textBox1.Text;
                Console.WriteLine("head {0}", System.Threading.Thread.CurrentThread.GetHashCode());
                onDataEntered.Tell(msg);   //<-- this looks like it is fired from within the current actor, but its not, its just an eventhandler, so there is no Sender here
            };
if you explicitly pass Self as sender, it works
onDataEntered.Tell(msg,Self);
the eventhandler is not bound to the actor context, as it is triggered by wpf/winform... so there is no active actor context that can act as a sender
If you put a breakpoint in the BodyActor receive handler, you see that the Sender is not the HeadActor
Roger Johansson
@rogeralsing
May 04 2015 16:50
you do need to capture Self first.
            var self = Self;
            dlg.textBox1.KeyUp += (e,s) =>
            {
                var msg = dlg.textBox1.Text;
                Console.WriteLine("head {0}", System.Threading.Thread.CurrentThread.GetHashCode());
                onDataEntered.Tell(msg,self);
            };
that will do it
Ralf Westphal
@ralfw
May 04 2015 16:58
yes, that does :-) thx for the help! i guess i have to rethink how a form and „its“ actor should be connected.
Ralf Westphal
@ralfw
May 04 2015 17:03
the form could depend on/own the actor (like in your bootcamp sample) or the other way around (like i wanted to do it). my idead was to encapsulate the form in the actor. so on a high level of abstraction there are only actors communicating. the form then is just a detail within an actor.