On Sun, Nov 28, 2004 at 11:17:40PM +0000, Nigel Sandever wrote: > This is the same bug/limitation of threads::shared I reported in perlbug > #30702. > > Then, it was essentially dismissed as being "working as designed": > > Nick Ing-Simmons wrote: > > When I 1st did the coding for sharing there was a deliberate policy > > not to do that. In general the contents of an array or hash can > > contain reference loops, so "walking" the contents to share it is > > slightly tricky (it has to be done depth first but breaking loops). > > > > So you are supposed to share the array/hash and then populate it, > > and loops etc. are programmer's problem. > > > > Scalars are shared using raw 'MAGIC' rather than a normal tie, which > > is slightly more efficent, and naturally gives access to the > > original value. > > I have to say that I disagree strongly. > > Whilst writing code to walk an arbitrary array or hash structure is very > complex to get right, doing it once, properly, in library code *has* to > be better than expecting every user to write their own! > > Without the ability to share previously populated datastructures, without > requiring them to be copied manually, (given that shared datastructures are > already duplicated per thread), makes having the notional ability to share > anything other than simple scalers almost useless.
I (perhaps erroneously) recall there being the suggestion that an additional function be provided to handle populated data structures and share() be left unchanged. But no one has come up to bat that I know of. > Add to that, that any attempt to lock() individual elements of a shared data > structure fail (upto 5.8.5), and you have a sharing mechnism that is alomost > useless.
