Re: use Devel::Pointer in threads

[LanX]

Well, I think you are trying to break thread safety and now you're getting bitten by undefined behavior.

> I know threads::shared can't share deep data structure,

according to the docs that's not true, you can share deep data structures as long as you also share any nested reference.

share(VARIABLE)

Shared variables can only store scalars, refs of shared variables, or refs of shared data (discussed in next section):

> and any fix for this approach?

You can always use shared_clone for read access.

And of course you can explicitly share singular scalars inside your nested data structure to allow writing.

shared_clone(REF)

shared_clone takes a reference, and returns a shared version of its argument, performing a deep copy on any non-shared elements. Any shared elements in the argument are used as is (i.e., they are not cloned).

If that's not good enough because you can't/don't want to predict the structure of your nested data, you might try Data::Dumper or Data::Dump for serializing it into a shared string. The receiving end can easily unpack it again.

[exilepanda]

I have a reason to attempt this, tho I know I will implement my own lock if this approach works. In fact, I have to assume I cannot predict how will the $Deep grows, but the $Deep can be really deep, like JSON. Child threads will read files and then further extend the structure tree, and every other child will work depends on the current tree to dig what they interest. That's why I can't declare explicitly ahead, nor a clone of the current helps.

I could have a safer approach by using DB, or deploy a thread to implement a TCP socket, so every child talk to the DB/Socket, but I try to use at least of I/O as possible.

[LanX]

Like I already said, I'd rather serialise data into a long string than to depend on undefined behaviour.

I mentioned Data::Dump* you mentioned JSON, so what's the problem?

Your trick to bypass "sharing" can segfault in worst case and is unreliable in best case.