18:10 <staticassert> has anyone thought about dependency injection? It seems like it would be nice to just say "I'm an actor and I need someone to pass me a Database actor" - and isntead of having to pass around a database actor's name you could just autowire it in

18:13 <jemc> staticassert: using an `interface` should meet exactly that goal

18:13 <jemc> instead of accepting an argument with a concrete type, use an interface type with the methods you need

18:14 <staticassert> I think that's solving a different problem. DI would mean I don't construct anything, I just ask for things, and some configuration that exists somewhere provides it. With interfaces, I'd get some of the benefits - like easier testing, but it wouldn't quite by the same.

18:34 <jemc> I think that what you're talking about can be solved with a combination of interfaces and careful design patterns to be sure that you're designing your code in such a way that it can be done as you describe, with the "configuration that exists somewhere" just being the higher-level code that sets up and executes your classes/actors

18:36 <jemc> also, I think "don't construct anything" is a bit of a red herring - if you use type parameters, you should be able to call constructors even when you don't know the concrete type

20:02 <obadz> SeanTAllen: new website is great!

20:31 <staticassert> pony is M:N threading right? Does that mean that IO in a userland thread blocks other userland threads that are mapped to the same OS thread? Or does the runtime manage this?

20:35 <jemc> staticassert: there have been some discussions about how to mitigate the effect, but yes, currently any long-running synchronous operation in an actor will block that scheduler thread

20:36 <jemc> the general recommendation is to not avoid *synchronous* I/O as much as possible

20:36 <staticassert> cool, thanks. have those discussions been during sync calls or somewhere written down?

20:38 <jemc> IIRC the discussion happened in last week's sync call, near the beginning

20:38 <jemc> could be wrong though - it was definitely a recent one

20:39 <jemc> sylvan had an idea about how to detect when to spin up another scheduler thread for the same logical "core"

20:39 <jemc> it was just an idea, though - not yet subjected to a lot of careful thought

20:41 <jemc> the current recommendation is that if you get into situations where that is a problem, you need to consider redesigning your data flow to be more asynchronous somewhere

20:41 <jemc> with any long-running blocking operations being a general anti-pattern

22:22 <SeanTAllen> obadz: thank you. more coming.

22:28 <SeanTAllen> staticassert: that depends on your definition of M:N

22:29 <SeanTAllen> there are many actors. but pony doesn't have threads. there are schedulers which by default, is set to the number of CPUs you have a available and schedulers run actors.

22:29 <SeanTAllen> there's not a thread per actor or anything like that

22:30 <SeanTAllen> you can use the --ponythreads option to change the number of schedulers

22:33 <SeanTAllen> depending on OS you can pin schedulers to CPUs which will give you excellent performance.

22:33 <SeanTAllen> when we run on linux we pin the pony threads plus use --ponypinasio to pin the asio thread as well

22:33 <SeanTAllen> basically what i am saying staticassert is that pony does not have green threads and that is often what people mean by M:N

22:46 <jemc> quick correction to a typo of mine I just noticed above

22:46 <jemc> I said "the general recommendation is to not avoid *synchronous* I/O as much as possible"

22:47 <jemc> it had an unintentional double-negative: "not avoid"

22:47 <jemc> I meant "the general recommendation is to avoid *synchronous* I/O as much as possible"

22:47 <jemc> hopefully that was clear from context, but this should clear up any confusion