lucerne has quit [Remote host closed the connection]
lucerne has joined #jruby
lucerne has quit [Remote host closed the connection]
lucerne has joined #jruby
lucerne has quit [Remote host closed the connection]
lucerne has joined #jruby
lucerne has quit [Remote host closed the connection]
lucerne has joined #jruby
<basshelal[m]>
enebo: Do you know if JNR-FFI supports passing and returning structs by value? as in `struct myStruct myFunction(struct myOtherStruct){...}`
<basshelal[m]>
I've written a test in JNR-FFI but it fails, I'm hoping I'm doing something wrong
<basshelal[m]>
All the code I've seen and used only uses `Pointer`s to structs like `struct myStruct * myFunction(struct myOtherStruct *){...}` which works fine but using value fails miserably.
<basshelal[m]>
I know you might not be the right person to ask but I think headius is on holiday
lucerne has quit [Read error: Connection reset by peer]
dan64[m] has joined #jruby
<dan64[m]>
Hi,
<dan64[m]>
why does JRuby work without a GIL?
<dan64[m]>
As I understand it, the default interpreter of Ruby has 2 concurrently running threads: one thread for interpretation and the other for file I/O.
<dan64[m]>
If my understanding of the default interpreter is correct, then I suppose that JRuby simply has 2 or more interpreter threads and file I/O threads. Is that right?
<dan64[m]>
The GIL is allowing non-thread safe code to work. So the C backend of the default Ruby interpreter can run without issues in the background. Is that correct as well?
<dan64[m]>
JRuby thus is incompatible with implementations using the C backend.
<dan64[m]>
IOW: So you cannot use gems that were implemented with a C backend.
<enebo[m]>
basshelal: I don't know. I only ever recall working directly with pointers
<basshelal[m]>
enebo:
<basshelal[m]>
yeah I saw the inner details of the code, it seems we do not support it, that's really disappointing... I'll have to see what I can do about that myself
<enebo[m]>
basshelal: cool. At some level perhaps it can just be referenced and then accessed through a pointer?
<enebo[m]>
lifespan of the value itself perhaps is an issue
<enebo[m]>
My C brain gets weaker and weaker as the years go on. I would assume values just end up on the stack?
<basshelal[m]>
Hmm that's not a terrible idea, lifespan is an issue indeed, the whole stack vs heap thing probably, I can probably just copy the values of the struct and have the actual memory be somewhere else
<basshelal[m]>
Yeah C feels like another dimension when you're deep in your nice higher level world
<enebo[m]>
I was just thinking about lowest code cost way since otherwise you would need to alloc something same size and copy to a safe piece of memory.
<enebo[m]>
Obviously copying a copy is not the fastest thing in the world either
<enebo[m]>
beside moving a value from the stack onto the heap
<enebo[m]>
I had not even encountered a struct by value piece of C code in decades until I saw more recent MRI C parser actually does it
<basshelal[m]>
Yeah I was thinking about the copy thing, but yeah performance will be a bit of an issue
<enebo[m]>
if your use of it is not to keep it around past what you call in Java you should be fine since it would be higher up in the stack but if you try and save it then it will go away.
<basshelal[m]>
Yeah it's not too common but people do apparently use it and we've actually had a couple of GitHub issues regarding this problem in one way or another
<basshelal[m]>
I've ran into it more than once now
<enebo[m]>
This may not be a problem since you are interacting with a foreign API which can crash the JVM already
<basshelal[m]>
Yeah the lifetime issue is why it's safer to copy the fields
<basshelal[m]>
What also sucks is that this is for both parameters AND return types
<basshelal[m]>
jffi has a `Invoker.invokeStruct()` function which does the returning one
<basshelal[m]>
But yeah I'll have to try out a bunch of different ideas and what works, thanks for the help
<enebo[m]>
yeah good luck. I will help if I can :)