3 ms·

Ok, so let's take an example. In a very hand-wavy way, the ZeroMQ messaging queue works without a central messaging broker or service, but purely as a library.

Ok, so let's take an example. In a very hand-wavy way, the ZeroMQ messaging queue works without a central messaging broker or service, but purely as a library. In theory, you can implement ZMQ messaging primitives in your language of choice, but this is a lot of work, so it is usually used through bindings to libzmq C library. I don't know exactly how it works, but at some point it writes things to some memory address. This is the point where the Rust compiler starts complaining about the situation if you try to use the bindings from something that can potentially be sent between threads. So you use some mutex, or a lock, and maybe wrap the whole thing in an atomic reference counted entity. What would be the Pony way of solving a situation like this? It does say that it is possible to directly call C or C++ libraries. I'd really appreciate if someone from the Pony community can elaborate a bit on such use cases.

spooneybarger 6y ago
I don't know enough about ZMG to answer this. What little I know about it is mostly from a pure Pony version that a member of the core team worked on quite some time ago. Joe is probably the best person to talk to if you want to use ZMG as a reference point, you can find him on the Pony Zulip. https://ponylang.zulipchat.com/# https://ponylang.zulipchat.com/#
- jgilias 6y ago
  It's sort of a general question though. What happens if I use a C library from Pony that does or can potentially do unsafe things. I'm not sure I understand how such situations can be solved without some kind of a locking mechanism. I mean, the answer can be 'just rewrite the underlying library in Pony'. Which would be fair enough.
  - spooneybarger 6y ago
    That's an incredibly general question. "It depends on the specifics" would be the general answer. Once you use FFI, there's no guarantee of memory safety as the C code has access to the entire address space of the process. There is no sandboxing of foreign code at this time. If the code you are calling isn't thread safe and you run your Pony program with more than 1 scheduler thread (pony actors get run on 1 or more scheduler threads- generally 1 per scheduler thread per CPU) then "bad things canhappen". Becaue you are running unsafe code that can be accessed from multiple threads- but... well, maybe you can structure the Pony API so that you don't do that. It really depends.
    - magicalhippo 6y ago
      > maybe you can structure the Pony API so that you don't do that So from what I could gather from a quick glance through the tutorial, that would be to restrict the C code calls to a single actor, and have other actors call, I guess primarily through the async behaviors?
      - spooneybarger 6y ago
        That would be the general approach if possible with c code that isn't thread safe. It's a matter of if that is possible with a given library (it's difficult for example with GTK).

spooneybarger 6y ago

I don't know enough about ZMG to answer this. What little I know about it is mostly from a pure Pony version that a member of the core team worked on quite some time ago. Joe is probably the best person to talk to if you want to use ZMG as a reference point, you can find him on the Pony Zulip. https://ponylang.zulipchat.com/# https://ponylang.zulipchat.com/#

jgilias 6y ago
It's sort of a general question though. What happens if I use a C library from Pony that does or can potentially do unsafe things. I'm not sure I understand how such situations can be solved without some kind of a locking mechanism. I mean, the answer can be 'just rewrite the underlying library in Pony'. Which would be fair enough.
- spooneybarger 6y ago
  That's an incredibly general question. "It depends on the specifics" would be the general answer. Once you use FFI, there's no guarantee of memory safety as the C code has access to the entire address space of the process. There is no sandboxing of foreign code at this time. If the code you are calling isn't thread safe and you run your Pony program with more than 1 scheduler thread (pony actors get run on 1 or more scheduler threads- generally 1 per scheduler thread per CPU) then "bad things canhappen". Becaue you are running unsafe code that can be accessed from multiple threads- but... well, maybe you can structure the Pony API so that you don't do that. It really depends.
  - magicalhippo 6y ago
    > maybe you can structure the Pony API so that you don't do that So from what I could gather from a quick glance through the tutorial, that would be to restrict the C code calls to a single actor, and have other actors call, I guess primarily through the async behaviors?
    - spooneybarger 6y ago
      That would be the general approach if possible with c code that isn't thread safe. It's a matter of if that is possible with a given library (it's difficult for example with GTK).