On Thu, Aug 02, 2001 at 12:39:56AM -0700, Wilkinson, Mike wrote:
> I'll continue to play with it, should be interesting to track down.
>
> A question to the group: there was some mention before of a multithreaded
> POE in progress - What form will this functionality take? Any ideas how well
> it will port to Windows?
>
> Just curious, since native multithreaded Windows processes can be hell to
> debug sometimes.
Threaded POE prototypes have always made sure that threads are
optional. They have gone so far as to run anyway (albeit poorly) when
threads are requested but not present.
In general, each Session may be spawned in its own thread upon
request. Otherwise they cooperatively multitask within the Kernel's
thread (thread 0?). The least invasive method of doing this seems to
be adding an option to the create() constructor:
POE::Session->create
( xyz_states =>
{ ...,
},
# Initial session options.
options =>
{ thread => 1,
},
);
I have not been able to make runtime $session->option( thread => 1 )
or 0 move the session into or out of a separate thread, so it would be
a creation-time option only.
At least one threaded POE prototype placed a Group class between
Kernel and Session, and threads (or not) were implemented there. This
allows several Sessions to run in a single Group (thread), or not.
Kernel -+- Group -+- Session (three in thread 1)
| |- Session
| `- Session
|- Group -+- Session (two in thread 2)
| `- Session
... (and so on)
Regardless how threads are encapsulated internally, only one event
handler can run at a time in any given thread. Since each session
exists entirely within a single thread, their event handlers remain
atomic and sequential. Programmers won't be required to add locks to
HEAP, SESSION, etc. Global variables will be a problem, but 90+% of
your code should already be thread safe, if I have my way.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
