HomePage | RecentChanges | Preferences


Erlang global process registry

wsmoak [7:45 AM] if I generate a project `mix new connect_four --sup` and then add some workers like ConnectFour.Game and ConnectFour.Player ... I can see in the observer that they get started under ConnectFour.Supervisor. (They're all Agents right now.) Later in the Game module code... how do I look up / find / talk to the players? Can I ask the supervisor for one of its children later, or am I supposed to be tracking that (the pid?) in the game itself?

wsmoak [7:49 AM] I'm looking at the Acquirex code, and he has the players 'join' the game. (I'm not using gen_fsm either.)

sasajuric [7:58 AM] @wsmoak: Iíd likely use gproc registration for that. I made some comments about it here:

reddit Generalizing AcquireX? to Multiple Simultaneous Games? ē /r/elixir AcquireX? Repo: This repo is great for looking at how to write OTP code, but with everything talking to each...

wsmoak [8:39 AM] thanks @sasajuric ! So it sounds like the simplest thing that can possibly work is indeed to remember the player pids in the Game's state. (which I realize will break if one gets re-started.) And the next thing appears to be using Process.whereis/1 since they are all registered with names.

sasajuric [8:41 AM] you can work around the failure problem if you use one_for_all in the parent supervisor

sasajuric [8:41 AM] thatís not perfect error isolation, but it simplifies things

sasajuric [8:41 AM] so if any game participant fails, the whole game fails

wsmoak [8:43 AM] Are there docs for gproc published anywhere? Searching, I keep getting back to github and the readme is pretty sparse. is the best I've found, but quite old. NEW MESSAGES

sasajuric [8:44 AM] @wsmoak: This is the reference I use:

GitHub uwiger/gproc gproc - Extended process registry for Erlang

sasajuric [8:45 AM] gproc is a bit strange initially, but once you get used to it itís pretty cool.

sasajuric [8:45 AM] Basically, for game participants, you could use reg/1 with {:p, :l, game_id}

sasajuric [8:46 AM] You need to do this from each process, gproc doesnít allow external registration (i.e. that one process registers some other process).

The registration above is non-unique, which allows you to register multiple processes under the same id

sasajuric [8:46 AM] first two atoms in the tuple in this case must be :p and :l (non-unique property, local)

sasajuric [8:47 AM] the third element in the tuple is arbitrary term, you might want to use something like {:player, game_id}

sasajuric [8:48 AM] finally, you could use wih {:p, :l, {:player, game_id}} to get all players (pids) of a particular game

And more discussion...

wsmoak [8:49 AM] ah, just read the markdown under docs, got it. thank you! gproc does seem like the right choice in the end. I need to trip over a few things that you already know first, and get there myself. :simple_smile:

fishcakez [8:50 AM] alternatively you can use {:n, :l, {game_id, player_id}} and use a select to get all players in a game

fishcakez [8:50 AM] gproc really has a lot of powerful functionality

wsmoak [8:51 AM] it's connect four. there are always, only, ever two players. :smile:

sasajuric [8:51 AM] @fishcakez: that will fetch just one player, right?

fishcakez [8:51 AM] @wsmoak: not how I play :disappointed:

fishcakez [8:52 AM] @sasajuric: you can use a select like {:n, :l, {gameid, :"_"}}

wsmoak [8:52 AM] lol... maybe if this ever works I will write the awesomely distributed multi-player three-dimensional version of connect four :stuck_out_tongue:

sasajuric [8:52 AM] @fishcakez: yeah, thatís a good point. I personally still prefer properties for that, but maybe I should consider matchspecs :simple_smile:

fishcakez [8:53 AM] properties are just matchspecs under covers so its just taste

sasajuric [8:53 AM] indeed, but in that case, I donít need to write them :smile:

sasajuric [8:53 AM] that being said, this reduces the pressure on the ETS table

fishcakez [8:54 AM] @sasajuric: Having read your thoughts on :gen_fsm we think so differently

sasajuric [8:54 AM] Somehow Iím not surprised :simple_smile:

sasajuric [8:55 AM] Not that itís bad or anything, but fsm processes personally confuse me. Itís obviously personal taste.

fishcakez [8:56 AM] yeah, I really like gen_fsm, probably my favourite.

fishcakez [8:57 AM] I think because I like to see the callgraph and only call functions when needed

fishcakez [8:57 AM] I find something like put_new a horrible function

sasajuric [8:58 AM] hmm, Iím not sure I understand what you mean by callgraph.

fishcakez [8:59 AM] the order the functions are called from one another

fishcakez [9:00 AM] if you imagine that a module is a graph with functions are vertices

fishcakez [9:00 AM] and a function call is an edge

sasajuric [9:01 AM] yeah, that can be helpful in more complex scenarios, though I personally didnít encounter such

sasajuric [9:01 AM] As I said, I usually read the code by looking at a single operation and asking myself how is this handled.

sasajuric [9:01 AM] Itís harder to get that answer in state-oriented graph

fishcakez [9:01 AM] Right I was saying how we think differently

sasajuric [9:01 AM] Exactly :simple_smile:

sasajuric [9:02 AM] But itís not just about fsms here. Another thing is that gen_fsm conflates FSM with message passing, which is another thing I dislike about it

fishcakez [9:03 AM] I missed that in the thread did you talk about it there?

sasajuric [9:03 AM] Yeah, wait, let me find that post

sasajuric [9:06 AM] @fishcakez: Ah, it looks like I didnít make it so explicit. The idea I mentioned is here: starting with ďGoing furtherĒ. The main point is under the code sketch.

augustorsouza [9:06 AM] is there a way to use less memory?

fishcakez [9:08 AM] @sasajuric: yeah I find your action orientated approach very OOP :stuck_out_tongue:

sasajuric [9:09 AM] Perhaps itís due to my OOP background. Regardles, thatís how I think about the problems :simple_smile:

fishcakez [9:09 AM] yeah I am just teasing though

sasajuric [9:10 AM] I certainly brought some OO baggage with me to Erlang. That being said, I donít think OO is 100% bad, and feel some principles apply universally.

fishcakez [9:10 AM] @augustorsouza: seems like a bug in rebar

fishcakez [9:11 AM] @sasajuric: but when I mention callgraph it is not so much about state/vertices but rather the flow or transitions

fishcakez [9:11 AM] (edges)

fishcakez [9:12 AM] that is probably why the telecom guys lap the gen_fsm up because they love the state transitions

fishcakez [9:12 AM] or girls

sasajuric [9:13 AM] Itís really about perspective. FSM puts states and transitions first. What Iím proposing puts actions first. You can slice it one way or another. As I said, FSM probably makes more sense when there are complex states, but most, if not all, cases I have seen were not complex enough.

sasajuric [9:13 AM] However, even if/when Iíd prefer FSM, Iíd like it to be decoupled from message passing. Why do I need a behaviour and messages for that? Thatís a completely separate mechanism, even if it will mostly map 1:1 to actions.

fishcakez [9:14 AM] yeah I find the exact opposite to you :confused:

fishcakez [9:16 AM] @augustorsouza: apparently not a rebar bug: just how it is

Elixir - Could not compile dependency idna Error message: iex -S mix Eshell V7.0 (abort with ^G) ==> idna (compile) Killed ** (Mix) Could not compile dependency idna, /root/.mix/rebar command failed. If you want to recompile this

sasajuric [9:17 AM] @fishcakez: Even with that different thinking, do you think FSM should be tightly-coupled with message passing?

fishcakez [9:17 AM] @sasajuric: I have mixed feelings on it but generally I like it

fishcakez [9:18 AM] I hate to say there is a problem when I am unsure what I would do differently

fishcakez [9:18 AM] bbl

fishcakez [9:18 AM] if I was to write my own gen_fsm type thing likely I would just end up re-implementing gen_fsm :confused:

sasajuric [9:22 AM] Yeah, as soon as I look the API of gen_fsm and see stuff like send_event, send_all_state_event, sync_send_event, sync_send_all_state_event, send_event_after and all those callback return tuples, my head goes fuzzy and my heart sinks :simple_smile:

sasajuric [9:22 AM] I canít help but thinking that gen_server with call/cast is way simpler, yet just as powerful. [10:39 AM] @sasajuric: OO isn't bad. Mutability isn't bad either. It's default mutability that leads to lots and lots of side-effect errors. [10:39 AM] Developers won't fight the defaults in a language because we're too busy trying to meet impossible deadlines :smile: (edited)

sasajuric [10:44 AM] I think OO and mutability are independent concepts. You could theoretically have immutable OO (though Iím not aware of an existing implementation). When I was refering to my OO baggage above, I wasnít talking about mutability. [11:04 AM] @sasajuric: They are independent concepts. [11:04 AM] It's just that most OO is mutable by default (aka imperative).

HomePage | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited October 13, 2015 4:45 pm by (diff)