<discocaml>
<darrenldl> (a bit of a hack in order to "yield" to domainslib task pool, but good enough for now)
<companion_cube>
What's a "gw" in this context?
<discocaml>
<darrenldl> gateway
<companion_cube>
Ah ok
<discocaml>
<darrenldl> meaningfully plays the role of Erlang's BEAM VM for later distribution cases
<companion_cube>
So what would it look like with two actual processes? :)
<companion_cube>
Right
<discocaml>
<darrenldl> (remote connection is then done at gateway level, with ssl, routing and all that jazz)
<discocaml>
<darrenldl> the output suggests the 3 processes do run concurrently
<discocaml>
<darrenldl> send is asynchronous, recv is blocking, not sure how to mimic `receive ... after` timeout syntax of sorts without appealing to custom effects
<discocaml>
<darrenldl> since we want the scheduler to be able to distinguish promises that are blocked because of no messages, and once that are blocked from internal work, i.e. we do not use the timeout value if any of the work has received an initial message
<discocaml>
<darrenldl> ones that are blocked from internal work*
<discocaml>
<darrenldl> re two separate processes: the idea is user will then need to construct a `Mailbox.Global.t`, which demands serialisation and deserialisation functions
<companion_cube>
And so typing will be enforced by deserialization
<discocaml>
<darrenldl> yep
<discocaml>
<darrenldl> some builtin send and recv functions are to be provided for basic types, and some combinators
<discocaml>
<darrenldl> but yeah local mailbox is the main "novelity" (ignoring how arguable it is) that side steps local send, recv costs
bartholin has quit [Quit: Leaving]
<companion_cube>
So is it just based on domainslib?
<discocaml>
<darrenldl> mostly to avoid touching effect syntax and use a premade task pool
<discocaml>
<darrenldl> but will have to roll its own scheduler and move away from domainslib eventually for timeout support etc
chrisz has quit [Ping timeout: 255 seconds]
<discocaml>
<darrenldl> domainslib channel would have been useful, but it blocks an entire domain it seems
gareppa has joined #ocaml
gareppa has quit [Remote host closed the connection]
<companion_cube>
Right, right, you'd need effects
alexherbo2 has joined #ocaml
xd1le has joined #ocaml
rf has joined #ocaml
<discocaml>
<darrenldl> now just need typed effects to land...
trillion_exabyte has quit [Ping timeout: 255 seconds]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
trillion_exabyte has joined #ocaml
rf has quit [Ping timeout: 252 seconds]
rf has joined #ocaml
Stumpfenstiel has joined #ocaml
<discocaml>
<geoff> having mailbox actors would be nice. That was one of my favourite things about F# when I was learning it (after elixir and before ocaml)
bartholin has joined #ocaml
<discocaml>
<darrenldl> might just bite the bullet and release a version for ocaml 5.0 just so people can play with it
<companion_cube>
Don't wait for typed effects
<companion_cube>
Afaik no one knows if and when they will land
<discocaml>
<darrenldl> is there at least a solution in mind at the theoretical level? (as in at least possible to type)
<discocaml>
<darrenldl> i kinda dont mind the current effect syntax too much, but very reasonable that we dont want end users running with it too much
<companion_cube>
No of course
<discocaml>
<darrenldl> fair enough
<companion_cube>
Never expose it, but use it underneath if it makes sense
<discocaml>
<darrenldl> easy enough
<discocaml>
<darrenldl> cant think of a good way to integrate with eio, oh well
<companion_cube>
You could build on top of eio
<companion_cube>
Reuse the scheduler
trillion_exabyte has quit [Ping timeout: 255 seconds]
trillion_exabyte has joined #ocaml
<discocaml>
<darrenldl> yes indeed, was going through its api again, and the fiber interface is too shiny to look past
<discocaml>
<Anurag> Its a good starting place, but depending on you might have to look into rolling your own if your scheduling needs need to be more opinionated. FWIW the `lockfree` library has the queue structures that should provide an excellent starting point for writing your own schedulers.
<discocaml>
<Anurag> As a learning exercice, I did some tests with a very simple scheduler design a while back, and even with a simple lock based queue I was able to get pretty far in terms of throughput/perf with some design choices that helped avoid contention between threads! Uncontended mutexes seem to perform reasonably well on linux.
<discocaml>
<darrenldl> im more concerned with a scheduling aware IO layer tbh, since doing that would just be repeating eio
<companion_cube>
@anurag the risk is that then you have two incompatible schedulers
<companion_cube>
Assuming eio gets to the dominant position that is
<discocaml>
<darrenldl> it seems to be on track to getting there
<companion_cube>
(i tested mutexes too, and for me it was ~15ns for uncontended lock+unlock iirc)
<discocaml>
<Anurag> companion_cube: That is true indeed. It'd be nice if the core effects needed to represent asynchronous operations were in a smaller layer (maybe even in the stdlib). Its also hard to predict what the dominent position in this space will look like a few years down the road. `eio` is the first one off the blocks, but the current dominant libraries are still Lwt (and to some extent Async), and I can see many reasonable positions one could take to
xd1le has quit [Quit: xd1le]
<companion_cube>
Seems to me like lwt is slowly maintained these days, and has no interest in using effects to improve their API (eg by adding an await operator)
<companion_cube>
Async could evolve to do that, but i don't see it becoming dominant because JST libraries are still kind of polarizing
<companion_cube>
(a smaller layer just for fibers would be great, yeah)
<discocaml>
<Anurag> True about async. Janestreet libraries are kinda opinionated. But the same is also true about EIO so I don’t know.
<companion_cube>
Yeah but eio doesn't have the JST, hmm, label
<companion_cube>
It's not just the opinionatedness, imho; it's also that it pulls a lot of heavy JST things, and is developed more are source-available that follows JST's own needs (see the versioning story)
<discocaml>
<Anurag> Re async exploring effects, when I asked on the ocamllabs slack a while back it sounded like they are experimenting with their modal types to have some type safety when they explore new designs with effects.
<companion_cube>
Maybe they became more open, idk.
<discocaml>
<Anurag> This is only an anecdote but almost all of the patches I’ve proposed in the past year or so (these are small patches to be fair) got feedback pretty quickly and most of them made their way onto the project trunk.
<discocaml>
<Anurag> It then again it’s definitely not going to be the same as a community managed project.
<discocaml>
<darrenldl> (eyeing at distributing work between domains with eio+domainslib): feels like the irreconcilable two scheduler problem again ugh
Serpent7776 has joined #ocaml
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
Haudegen has joined #ocaml
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #ocaml
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #ocaml
chrisz has joined #ocaml
Stumpfenstiel has quit [Quit: No Ping reply in 180 seconds.]
Stumpfenstiel has joined #ocaml
Anarchos has joined #ocaml
John_Ivan has quit [Read error: Connection reset by peer]
azimut has quit [Ping timeout: 255 seconds]
alexherbo2 has quit [Ping timeout: 260 seconds]
John_Ivan has joined #ocaml
alexherbo2 has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
<discocaml>
<Marwoops> do you have any menhir / ocamllex guide to recommend to write a lexer and a parser ?