<brainproxy>
not all JS engines implement it, but it's in node for example and there are shims using postMessage and MessageChannel for browsers that support those
<brainproxy>
i realize that's a callback based thing and Timer / TimerNotify are structured differently, but I'm curious if it's possible to do something conceptually similar to setImmediate, i.e. schedule things ASAP but not ahead of other things that may have been sheduled in the meantime
<SeanTAllen>
what does set immediate do exactly?
<SeanTAllen>
in general, you wouldnt use a timer to do what setImmediate does (if I understand it correctly). You would, stop processing your behavior and as a last step, call a behavior on yourself to start again.
<SeanTAllen>
That new behavior will not be run during the current scheduler run.
<SeanTAllen>
This is what TPCConnection does when it calls `read_again`.
<brainproxy>
it schedules a callback to be run on the next turn of the event loop, but if other events are already in the queue (I/O related or whatever really) those will get run first
<SeanTAllen>
that sort of pattern is probably what you want.
<brainproxy>
i think so; if i understand correctly, an op such as read_again won't hog the scheduler
<brainproxy>
meaning i had lots of actors doing read_again like ops, they would end up interleaved w.r.t. the scheduler
<brainproxy>
if* I had
<SeanTAllen>
think of it more like this
<SeanTAllen>
when a scheduler runs an actor
<SeanTAllen>
it will run up to 100 messages
<SeanTAllen>
or until it runs out of messages in the queue at the time it started running
<SeanTAllen>
so
<SeanTAllen>
when _read_again is called
<SeanTAllen>
it wont be run until the next time the actor gets scheduled
<SeanTAllen>
so you are yielding and saying, "run me again later, starting at this behavior"
<brainproxy>
gotcha; okay good, now I know what to reach for if I want to do that kind of thing; pony is my first experience w/ actors
<jbk>
though with it being multi-threaded, it may not need to be used as much as in JS
<brainproxy>
true, i was thinking more along lines of "how do I break up a big loop, but w/o using a timer per se"
<brainproxy>
and in such a way that multiple instances of doing that could tie up all the scheduler threads
<brainproxy>
if i didn't break up the loop, i mean
<SeanTAllen>
brainproxy: that is what TCPConnection is doing, breaking up a potentially really big loop of "read until there is no more data"
<brainproxy>
got it
<brainproxy>
the pony book is really great btw
<SeanTAllen>
jbk: if you only have 1 cpu, pony will be single threaded
<SeanTAllen>
there's 1 scheduler per cpu
<SeanTAllen>
brainproxy: thanks. its been a collective effort and we happily accept new contributions if you find anything lacking or in need of improvement.
<brainproxy>
i'll probably re-read it at some point, after I've spent more time w/ pony, and i'll definitely cook up some pull requests or at least chime in if something jumps out at me
<jbk>
true... though with something like node there is always one (OS) thread
<SeanTAllen>
the pattern i just described to you isn't written up anywhere so, feel free to write up a Pony Pattern for it once you get the hang of it.
<SeanTAllen>
jbk: indeed
<jbk>
and can't you override the number of threads if you want?
<brainproxy>
the only thing I can think of atm is that `struct` just suddenly appears in one of the sections
<brainproxy>
so I was like "wait, was that explained somewhere"
<brainproxy>
and doing a google site search i found that was not the case
<SeanTAllen>
jbk: you can, although i will be doing a PR soon to not allow more threads than CPUs as the runtime doesn't perform well in that case.
<SeanTAllen>
brainproxy: struct is for C-FFI. so perhaps a better example that doesn't use C-FFI might make sense there, or an explanation of what struct is doing there. can you post a link to where `struct` makes that appearance?
<SeanTAllen>
or open an issue on the tutorial repo pointing out that its confusing