returning table from love.thread

[farzher]

Do I have to serialize my table as some kind of string or whatever then unserialize it in my main thread?

There's no way to pass a reference to a table in a thread back to the main process? Or pass a reference to a table into the thread for it to edit?

The whole point of my thread is to generate a huge table, deserializing in the main thread will lag me

[zorg]

Channel:push mentions (along with Channel:supply for that matter) that the allowed types you can send are what are described in the Variant article. In other words, flat tables are also supported. If your tables aren't flat, then yes, you'd need to serialize/flatten them in some way.

But no, the data will be copied in all cases... FFI might allow you to create a memory region you could (ab)use by sending its pointer to another thread as a number or string... but i faintly recall me being told that that may not work either; haven't tested it yet so i can't give a concrete answer.

[s-ol]

Channel:push mentions (along with Channel:supply for that matter) that the allowed types you can send are what are described in the Variant article. In other words, flat tables are also supported. If your tables aren't flat, then yes, you'd need to serialize/flatten them in some way.

But no, the data will be copied in all cases... FFI might allow you to create a memory region you could (ab)use by sending its pointer to another thread as a number or string... but i faintly recall me being told that that may not work either; haven't tested it yet so i can't give a concrete answer.

Im not sure if ffi allocated memory works but you can just use a FileData and getPointer()

[zorg]

Im not sure if ffi allocated memory works but you can just use a FileData and getPointer()

Technically, both pointers would be numbers, so it should work for both cases, the difference has to do with whether FileData gets duplicated (one copy per thread) or it's only ever just one instance being "shared" across threads (if it's the duping case, getPointer is kinda worthless). Gonna test that out tomorrow.

Edit: After testing and actually finding one relevant sentence at the top of the love.thread article on the wiki, s-ol is right in löve userdata being shared across threads; one only needs to send their references.

[s-ol]

Im not sure if ffi allocated memory works but you can just use a FileData and getPointer()

Technically, both pointers would be numbers, so it should work for both cases, the difference has to do with whether FileData gets duplicated (one copy per thread) or it's only ever just one instance being "shared" across threads (if it's the duping case, getPointer is kinda worthless). Gonna test that out tomorrow.

I'm pretty sure the metadata (pointer value) gets duped but the memory is the same. An ImageData is basically a FileData too and thats how you preload images in a different thread / make a loading animation.

[raidho36]

Both ImageData and FIleData inherit from base class Data. They're not the same, and their respective cloning functions also differ.

[s-ol]

Both ImageData and FIleData inherit from base class Data. They're not the same, and their respective cloning functions also differ.

I don't see a cloning function in either implementation, and love.event just uses a Variant which holds a simple pointer as far as I can tell.

https://bitbucket.org/rude/love/src/150 ... ew-default
https://bitbucket.org/rude/love/src/150 ... ew-default

the Mutex in ImageData is only used to implement mapPixel thread-safely to guarantee it is atomic.

[farzher]

That's all very interesting, but also very confusing. If it's possible could someone put a simple example code for it?

I tried for now just sending serialized table data back, but I'm sometimes getting a stackoverflow error in the thread when calling channel:push for an unknown reason. and other times channel:deamnd freezes forever. I assume it's because I'm trying to send a 200,000 byte string (although I tried chunking it up into small pieces and still got errors)