Re: [osv-dev] shm_open / shm_unlink

2021-10-12 Thread Rick Payne
Hi Greg, Yes - it would be great to get support for elixir. I did try and engage with the elixir community before to see how we could use the same tooling - but I didn’t get much back. I’ll contact you off list… Cheers Rick > On 13 Oct 2021, at 06:53, Gregory Burd wrote: > >  > Rick, > >

Re: [osv-dev] shm_open / shm_unlink

2021-10-12 Thread Gregory Burd
Rick, I've been following your work with rebar3 and considering adapting it into distillery (https://github.com/bitwalker/distillery). I'd love to be able to generate an image (AMI, or whatever format) that is the combination of OSv, Elixir, BEAM, etc. in a single easy step. Thanks for digging

Re: [osv-dev] shm_open / shm_unlink

2021-10-04 Thread Rick Payne
On Mon, 2021-10-04 at 10:37 +0300, Nadav Har'El wrote: > You're welcome. If you have patches that might be useful to others as > well, please post them. Will do. Not there yet - but once I can verify things, I'll send patches.. Cheers Rick -- You received this message because you are

Re: [osv-dev] shm_open / shm_unlink

2021-10-04 Thread Nadav Har'El
On Mon, Oct 4, 2021 at 10:27 AM Rick Payne wrote: > Hi, > > On Mon, 2021-10-04 at 09:38 +0300, Nadav Har'El wrote: > > > > So the good (?) news is that the shm_* code didn't matter at all. > > Maybe it isn't even getting used... The problem is something > > completely different: > > Ah, I think

Re: [osv-dev] shm_open / shm_unlink

2021-10-04 Thread Rick Payne
Hi, On Mon, 2021-10-04 at 09:38 +0300, Nadav Har'El wrote: > > So the good (?) news is that the shm_* code didn't matter at all. > Maybe it isn't even getting used... The problem is something > completely different: Ah, I think the shm_open is still relevant. For now I'm including the musl file

Re: [osv-dev] shm_open / shm_unlink

2021-10-04 Thread Nadav Har'El
On Sun, Oct 3, 2021 at 3:27 PM Rick Payne wrote: > > On Sun, 2021-10-03 at 11:04 +0300, Nadav Har'El wrote: > > I'm curious where - > > Maybe we have a bug in our /dev (fs/devfs/*) implementation? It > > should generate good errors when trying to open /dev/shm/something - > > not assertion

Re: [osv-dev] shm_open / shm_unlink

2021-10-03 Thread Rick Payne
On Sun, 2021-10-03 at 11:04 +0300, Nadav Har'El wrote: > I'm curious where - > Maybe we have a bug in our /dev (fs/devfs/*) implementation? It > should generate good errors when trying to open /dev/shm/something - > not assertion failures and crashes. Well, this is one of those rabbit holes...

Re: [osv-dev] shm_open / shm_unlink

2021-10-03 Thread Nadav Har'El
On Sun, Oct 3, 2021 at 10:49 AM Rick Payne wrote: > On Sun, 2021-10-03 at 10:38 +0300, Nadav Har'El wrote: > > > > Shared memory support was never a big priority because it's main use > > case is multiple processes that want to share memory, and those > > (multiple processes) were never a thing

Re: [osv-dev] shm_open / shm_unlink

2021-10-03 Thread Rick Payne
On Sun, 2021-10-03 at 10:38 +0300, Nadav Har'El wrote: > > Shared memory support was never a big priority because it's main use > case is multiple processes that want to share memory, and those > (multiple processes) were never a thing in OSv. However, you're right > that it's a shame to lose

Re: [osv-dev] shm_open / shm_unlink

2021-10-03 Thread Nadav Har'El
On Sun, Oct 3, 2021 at 10:08 AM Rick Payne wrote: > > I've been playing around with my rebar3_osv tool (which turns an erlang > application into an OSv image). I'm trying to move everything to the > latest erlang release (24.1). > > OTP-24 comes with asmjit which can give quite a performance

[osv-dev] shm_open / shm_unlink

2021-10-03 Thread Rick Payne
I've been playing around with my rebar3_osv tool (which turns an erlang application into an OSv image). I'm trying to move everything to the latest erlang release (24.1). OTP-24 comes with asmjit which can give quite a performance boost in some cases. However, it requires the use of shm_open