(AS 5.8.6, WinXP Pro)

I've got a fairly large scale threaded app (using Thread::Apartment) that is configured as a Win32 Service via Win32::Daemon. I've isolated all the Win32 Service stuff to a Singleton apartment threaded container object named Win32Service.

Creating, starting, and querying the service works fine. However, whenever the container object attempts to access a threads::shared structure after calling Win32::Daemon::StartService(), all threads::shared objects seem to lose their tie; here's an error reported after wrapping an eval { } around the reference to the threads::shared hash:

Can't locate object method "FETCH" via package "threads::shared::tie" 
+at C:\Perl\MyPerlDaemon/Win32Service.pm line 237.
[download]

Note that the rest of the threads in the app (which do not reference Win32::Daemon::StartService()) retain their threads::shared access - to the same structure that fails in the Win32::Daemon container object.

Does anyone have any idea what would cause a threads::shared object to lose its tie under these circumstances ?

Update:

Once again, a bit more digging uncovers a solution (tho not an explanation of the root behavior). In my original implementation, Win32::Daemon::StartService() was called before the threads::shared structure was created and instantiated in the Win32Service thread object. On a whim, I decided to create the shared structure before starting the Win32 Service, and install it as a class variable in Win32Service. Lo and behold, it now works just fine.

Note that I've used Thread::Apartment and Thread::Queue::Duplex to pass shared objects created long after the receiving threads are created. That ability is key to Thread::Apartment operation, in order to create thread pools early to limit the amount of context cloned into threads, and then pass threads::shared client proxy objects around for inter-object interfaces. So I can only assume that Win32::Daemon does something unexpected with the threads::shared code (as BrowserUk has suggested).