If you would go with s external binary, then I think that port or port driver would be much better than creating TCP connection between the two.
hauleth
amnu3387
Yeah I think that in the end that would be the most reliable - right now I got a unix socket working and I can paint a window on command already - the issue I’m foreseeing is how to handle crashes issues on the render side so ports could help with that.
0
amnu3387
In terms of security you mean your program, when written safely, being safe to use by a user without leading to memory access shenanigans that you might, without intention, introduce in a C program right?
0
dimitarvp
ityonemo
Note that ‘safety’ from the erlang vm pov is not the same as ‘safety’ from the rust pov. When you are a safe nif, one thing is that you must never, ever cause a panic or segfault because that will completely upend all of the isolation and protection guarantees that you get with the vm, unless you are in distributed erlang and have taken the pains to work out cross-node failover.
Rust will happily panic on if you buffer overflow or have an error on malloc, or a ton of other things, because it’s priority is to prevent creating side channels that can be used to exfiltrate data, and for that security model, taking down the entire process is preferable to security problems.
Which is to say, rust does not guarantee you nif safety out of the box. You absolutely need to write tests that exercise the hell out of your nifs to be confident these scenarios do not happen.
There’s also some weird **** in the vm. When writing an async bridge between yielding nifs and my zig code, I found that there was a place where I absolutely needed to have a 10ns sleep or else it would cause the erlang vm to sporadically segfault. Don’t know why that’s the case, it’s not something that I can be confident I’ll ever know. I didn’t even have a good reason for putting that nano sleep exactly there, it was just a gut feeling.
1
elcritch
Take a look at Nim and Nimler if C and linking seems too intimidating. Nim is much easier to learn than Rust but still provides memory safety by default. It’s become my default for NIF’s since it’s new GC plays well with BEAM. Glfw might require some fiddling with linking but the forums are helpful.
Edit: actually the nimler docs is probably better than its github: Getting started - nimler
Plus, Nim has been used in a few moderate sized games. There’s decent OpenGL libraries like NimGL or nim glfw. Or a cool looking 2d library, pixie.
Happy hacking!
P.S. If you use long running NIF’s they’ll need to be marked as “dirty nifs”. Also I wouldn’t worry upfront about killing beam, it’s just that we get used to the beam rarely ever dying. It sounds like you’re interested in local ui stuff anyway.
2
amnu3387
Yeap, I tried out some examples from the rust book (?) and even went looking at my backups to see if I still had one piece where I did some assignment that I thought was non-sensical to compile and it did so I was a bit confused on how that was possible (in light of what I had heard - it’s a bit vapid because I don’t have the example anymore and it could totally be my own noobness and normal that it would compile).
What I wanted to understand in terms of using NIFs or other ways of running external to the VM code was what would be the best approach for instance to driving an OpenGL context. NIFs right now seem a bit out of my league. I ended up doing a port managed by a statem, and the statem is actually the one driving the loop with 5ms timeouts. Architecturally it looks pretty clean, the timeout can be shortened to less if needed still, but for 60fps, I need 16ms cycles, so it seems a port is totally able to drive this.
statem->5ms timeout cycle->port_command::2->c read switch->redraw
I also tried with a unix socket and it worked fine, but my thinking was it would make it more difficult if someday I wanted to port it over to other archs? Besides having to take care of a bit more stuff when handling it. I’m now looking into how to pass file descriptors between C programs and between those and the BEAM (not even sure you can, sockets seemed to be difficult in that it needs a lot of ritual due to the ownership/security of the socket) fun 
Probably there’s some dragons lurking around - at 10ns you’re probably hitting some race condition?
1
amnu3387
Thanks, I will have a look at it too.
I ended up ditching GLFW and going for OpenGLES right now, following, the linking became much easier GLESv2 EGL X11 and it’s up, GLFW I was having some trouble understand the loaders and what I actually needed to make it run, between glew’s glut’s and glwtf.
It helped that this book had a great example and source code http://www.opengles-book.com
Right now I’m using gcc and make - just everything in a single gcc invocation, imagine doing it properly will be another adventure.
1
ityonemo
For long running you can also do threaded and yielding nifs too! Well, I don’t know about other language support for it, but ABI supports it. You can see the differences in action here:
Starting at about 10m30s
1
amnu3387
That was a great example. Zig looks nice and zigler seems like a perfect bridge. I will check the details of what you did when I have some more time. 
0