The line in question is trying to assign $send_socket to a shared structure. $send_socket is a IO::Socket::INET object. Internally, that is a hash, probably containing other nested data structures.

You would need to share that hash, and everything in it to be able to assign it to a shared hash. You cannot.

There are two reasons for this.

1. You cannot share a bless reference (object).

   This is because blessing, involves associating (through internal linking (termed "magic")), the data pointed at by that reference with code (the object methods). But Perl cannot run code across threads.

2. Because if you could share that reference, it would be emptied of it's contents.

   An object without it's instance data is not going to work.

I have seen a reference that says that you can share Perl's object's across threads. The trick (apparently) is to re-bless the (copy of the) object handle available in the (other, non creating) threads where you want to use it.

This is a fine idea, but for it to work, you would first have to deep copy all of the contents of the blessed reference into a previously shared hash. You also have to copy any and all nested data structures referenced from it into new, shared equivalents.

I have tried to do this for some fairly simple objects, but it is very, very, very hard to do at the Perl level. Discovering the structures, and their classes for something as complex as an IO::Handle::INET object would be fraught with problems.

Basically what I am saying is that I cannot do what you are trying to do, and I know of noone who has succeeded in doing it.

If you decide to go ahead and try it anyway, I think that you are very much on your own:

• With how to even ebgin to tackle the problem.
• With trying to get assistance if things don't work.

Very few people will even consider trying to render assistance if you tell them that you are trying to share objects between threads. Even fewer will be responsive to bug reports against modules if you tell them you are encountering problems with their modules, when trying to share objects across threads.

I wish it wasn't so, but it is.

Good luck.

Thx mate. You should write the Advanced version of perlthrtut http://www.perldoc.com/perl5.8.0/pod/perlthrtut.html Actually, I've managed to re-design that bit, so I'll be creating sockets within threads, instead of shared. Cheers Chris

YW. Maybe one day, I'll know enough.

For now, I am not even sure that I know, what I don't know on the subject. I am already discovering things I thought I knew, and have stated publically without challenge--often several times--are incorrect. How much more of what I think I know, is? I'd hate to put out YABHT document or tutorial.

I've sat down to try and collate those bits of knowledge I have acquired relating to iThreads, on a couple of occasions. Each time, I realise just how many holes there are in what I know. All of what I know is derived soley from their use, and their use on my preferred platform; Win32. Some, or all of that knowledge may be completely invalidated on other platforms.

I've attempted to fill these holes by reading the sources to threads & threads::shared a few times, but I find XS almost unintelligable. Understanding comes with use, and I have never been a lover of writing C code, despite having been doing it for over 15 years (on and off). XS is like a completely different language with it's own syntax; short and obscure library function names; and not a lot by way of documentation. It's something I think you can only learn by doing, and as it's ultimately a dead end in it's current form, of no real interest to me.

Thread related questions don't always get the best response from the die-hard "fork() was good enough in my day" crowd--either here or elsewhere--so what I know comes soley from my own explorations of the subject. Learning in a vacuum is doubley hard.

Ultimately, I don't even like the current design of Perl threads. There are just too many holes in the design that stem directly from the underlying Pthreads API, on which it is quite tightly based. The unfortunate thing is, that this design looks set to persist into P6 :(

---

Examine what is said, not who speaks.

"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon