Re: Thread::Apartment, how do I use main:: subs?

[renodino]

Sorry, my memory is a bit fuzzy on T::A, but iirc the current version didn't play well outside of an explicitly created object, so main:: might not be runnable in an apartment. I vaguely recall trying to hack something together to do that for an apartment threaded Tk.

My own use of T::A has always been to use main:: as a just a launcher, and any actual processing was wrapped in objects which could be mapped to apartments.

Sorry I can't shed more light; I used T::A for a major project a couple years ago, but haven't had a reason to touch it in awhile.

[wilsond]

What I've done (maybe temporary) is to use main to spawn a package called LeafBridge::Client within the main thread and use that to spawn the LeafBridge::Client::Controller apartment. On spawn of this controller, I pass in the handle to $self (LB::Client). LB::C::Controller spawns all of the other apartments by calling $client->spawnApartment($controllerClient). $client being the LB::Client handle that was passed in and $controllerClient being the T::A::Client handle. That spawnApartment is called in the context of the LB::C::Controller apartment thread, not in the main thread. Since LB::Client doesn't do anything except run a loop that calls $controller->tick every second, it doesn't really do anything else but provide access to the apartment creation functions and to create the first apartment (LB::C::Controller). LB::C::Controller tracks all apartment threads and allows any apartment to talk to any other apartment by calling $controller->thread('LeafBridge::Client::XMPP')->send(@args) (the thread method passes the T::A::Client handle of the LB::C::XMPP apartment to the caller; send() is a method within the LB::C::XMPP apartment itself (it could be any arbitrary method in the requested apartment thread)). It seems to work well for now. It feels hackish, but it's the best I could do with the knowledge I have right now.

[wilsond]

By the way, the "workaround" I've presented above is terribly inefficient. My app is running at 400MB right now and it hardly does more than load. Memory leak anyone? It's beyond time for me to be digging myself out of that leak. *whee*

[BrowserUk]

My app is running at 400MB right now and it hardly does more than load.

I found the same thing when I played with T::A a year or two ago. Huge memory usage and glacial speed for relatively little gain.

In my experience, nearly everything you want to do with threads is easier, lighter and faster using threads directly. So long as you're not wedded to everything being OO, there is rarely a genuine need to pass complex objects around between threads.

[wilsond]

It wasn't a memory leak. I told it to make a pool of 30 threads at startup. 30 * too much memory = way too much memory. I have it down to 90MB right now, but that is still very, very high. Lots of tweaking to go.