{ "content": [ { "type": "text", "text": "# POE::Kernel (perldoc)\n\n## NAME\n\nPOE::Kernel - an event-based application kernel in Perl\n\n## SYNOPSIS\n\nuse POE; # auto-includes POE::Kernel and POE::Session\nPOE::Session->create(\ninlinestates => {\nstart => sub { $[KERNEL]->yield(\"next\") },\nnext => sub {\nprint \"tick...\\n\";\n$[KERNEL]->delay(next => 1);\n},\n},\n);\nPOE::Kernel->run();\nexit;\nIn the spirit of Perl, there are a lot of other ways to use POE.\n\n## DESCRIPTION\n\nPOE::Kernel is the heart of POE. It provides the lowest-level features: non-blocking multiplexed\nI/O, timers, and signal watchers are the most significant. Everything else is built upon this\nfoundation.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **USING POE** (9 subsections)\n- **PUBLIC METHODS** (100 subsections)\n- **PUBLIC EXPORTED VARIABLES**\n- **DEBUGGING POE AND PROGRAMS USING IT**\n- **ENVIRONMENT VARIABLES FOR TESTING**\n- **SEE ALSO**\n- **BUGS**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "POE::Kernel", "section": "", "mode": "perldoc", "summary": "POE::Kernel - an event-based application kernel in Perl", "synopsis": "use POE; # auto-includes POE::Kernel and POE::Session\nPOE::Session->create(\ninlinestates => {\nstart => sub { $[KERNEL]->yield(\"next\") },\nnext => sub {\nprint \"tick...\\n\";\n$[KERNEL]->delay(next => 1);\n},\n},\n);\nPOE::Kernel->run();\nexit;\nIn the spirit of Perl, there are a lot of other ways to use POE.", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 17, "subsections": [] }, { "name": "DESCRIPTION", "lines": 10, "subsections": [] }, { "name": "USING POE", "lines": 1, "subsections": [ { "name": "Literally Using POE", "lines": 18 }, { "name": "Using POE::Kernel", "lines": 21 }, { "name": "Anatomy of a POE-Based Application", "lines": 15 }, { "name": "Sessions", "lines": 23 }, { "name": "Resources", "lines": 78 }, { "name": "Session Lifespans", "lines": 16 }, { "name": "Events", "lines": 29 }, { "name": "handle_error", "lines": 1 }, { "name": "Using POE with Other Event Loops", "lines": 127 } ] }, { "name": "PUBLIC METHODS", "lines": 3, "subsections": [ { "name": "Kernel Management and Accessors", "lines": 25 }, { "name": "run", "lines": 1 }, { "name": "run", "lines": 8 }, { "name": "run", "lines": 22 }, { "name": "run_one_timeslice", "lines": 2 }, { "name": "run_one_timeslice", "lines": 1 }, { "name": "run", "lines": 2 }, { "name": "run_one_timeslice", "lines": 15 }, { "name": "run_while", "lines": 22 }, { "name": "has_forked", "lines": 7 }, { "name": "stop", "lines": 13 }, { "name": "stop", "lines": 2 }, { "name": "stop", "lines": 12 }, { "name": "post", "lines": 15 }, { "name": "post", "lines": 1 }, { "name": "post", "lines": 23 }, { "name": "Synchronous Messages", "lines": 15 }, { "name": "call", "lines": 2 }, { "name": "call", "lines": 1 }, { "name": "call", "lines": 17 }, { "name": "call", "lines": 36 }, { "name": "alarm", "lines": 41 }, { "name": "alarm", "lines": 3 }, { "name": "alarm_add", "lines": 21 }, { "name": "alarm_add", "lines": 1 }, { "name": "delay", "lines": 15 }, { "name": "delay", "lines": 18 }, { "name": "delay", "lines": 1 }, { "name": "delay_add", "lines": 21 }, { "name": "delay_add", "lines": 7 }, { "name": "alarm_set", "lines": 17 }, { "name": "alarm_set", "lines": 3 }, { "name": "alarm_adjust", "lines": 29 }, { "name": "alarm_adjust", "lines": 5 }, { "name": "alarm_remove", "lines": 1 }, { "name": "alarm_set", "lines": 46 }, { "name": "alarm_remove_all", "lines": 2 }, { "name": "alarm_remove_all", "lines": 11 }, { "name": "delay_set", "lines": 15 }, { "name": "delay_adjust", "lines": 117 }, { "name": "alias_set", "lines": 7 }, { "name": "alias_set", "lines": 3 }, { "name": "alias_remove", "lines": 15 }, { "name": "alias_remove", "lines": 5 }, { "name": "alias_resolve", "lines": 1 }, { "name": "alias_set", "lines": 11 }, { "name": "alias_list", "lines": 82 }, { "name": "select_read", "lines": 25 }, { "name": "select_read", "lines": 1 }, { "name": "select_write", "lines": 3 }, { "name": "select_write", "lines": 1 }, { "name": "select_expedite", "lines": 6 }, { "name": "select_expedite", "lines": 1 }, { "name": "select_pause_read", "lines": 4 }, { "name": "select_resume_read", "lines": 3 }, { "name": "select_pause_read", "lines": 1 }, { "name": "select_resume_read", "lines": 1 }, { "name": "select_pause_read", "lines": 5 }, { "name": "select_resume_read", "lines": 1 }, { "name": "select_pause_write", "lines": 3 }, { "name": "select_resume_write", "lines": 1 }, { "name": "select_resume_read", "lines": 3 }, { "name": "select_expedite", "lines": 21 }, { "name": "Session Management", "lines": 145 }, { "name": "detach_child", "lines": 10 }, { "name": "detach_child", "lines": 4 }, { "name": "detach_myself", "lines": 6 }, { "name": "detach_child", "lines": 3 }, { "name": "Signals", "lines": 214 }, { "name": "Signal Watcher Methods", "lines": 3 }, { "name": "sig", "lines": 32 }, { "name": "sig", "lines": 1 }, { "name": "sig_child", "lines": 8 }, { "name": "sig_child", "lines": 3 }, { "name": "sig_child", "lines": 9 }, { "name": "sig_child", "lines": 14 }, { "name": "sig_handled", "lines": 7 }, { "name": "sig_handled", "lines": 10 }, { "name": "signal", "lines": 16 }, { "name": "signal", "lines": 11 }, { "name": "signal_ui_destroy", "lines": 12 }, { "name": "Event Handler Management", "lines": 11 }, { "name": "state", "lines": 40 }, { "name": "Public Reference Counters", "lines": 20 }, { "name": "refcount_increment", "lines": 1 }, { "name": "refcount_increment", "lines": 17 }, { "name": "refcount_increment", "lines": 5 }, { "name": "refcount_decrement", "lines": 1 }, { "name": "refcount_increment", "lines": 11 }, { "name": "refcount_decrement", "lines": 6 }, { "name": "Kernel State Accessors", "lines": 7 }, { "name": "get_active_session", "lines": 13 }, { "name": "get_active_event", "lines": 9 }, { "name": "get_event_count", "lines": 3 }, { "name": "get_next_event_time", "lines": 1 }, { "name": "time", "lines": 1 }, { "name": "poe_kernel_loop", "lines": 2 }, { "name": "Session Helper Methods", "lines": 3 }, { "name": "session_alloc", "lines": 8 }, { "name": "Miscellaneous Methods", "lines": 6 } ] }, { "name": "PUBLIC EXPORTED VARIABLES", "lines": 23, "subsections": [] }, { "name": "DEBUGGING POE AND PROGRAMS USING IT", "lines": 225, "subsections": [] }, { "name": "ENVIRONMENT VARIABLES FOR TESTING", "lines": 9, "subsections": [] }, { "name": "SEE ALSO", "lines": 2, "subsections": [] }, { "name": "BUGS", "lines": 7, "subsections": [] } ], "sections": { "NAME": { "content": "POE::Kernel - an event-based application kernel in Perl\n", "subsections": [] }, "SYNOPSIS": { "content": "use POE; # auto-includes POE::Kernel and POE::Session\n\nPOE::Session->create(\ninlinestates => {\nstart => sub { $[KERNEL]->yield(\"next\") },\nnext => sub {\nprint \"tick...\\n\";\n$[KERNEL]->delay(next => 1);\n},\n},\n);\n\nPOE::Kernel->run();\nexit;\n\nIn the spirit of Perl, there are a lot of other ways to use POE.\n", "subsections": [] }, "DESCRIPTION": { "content": "POE::Kernel is the heart of POE. It provides the lowest-level features: non-blocking multiplexed\nI/O, timers, and signal watchers are the most significant. Everything else is built upon this\nfoundation.\n\nPOE::Kernel is not an event loop in itself. For that it uses one of several available POE::Loop\ninterface modules. See CPAN for modules in the POE::Loop namespace.\n\nPOE's documentation assumes the reader understands the @ offset constants (KERNEL, HEAP, ARG0,\netc.). The curious or confused reader will find more detailed explanation in POE::Session.\n", "subsections": [] }, "USING POE": { "content": "", "subsections": [ { "name": "Literally Using POE", "content": "POE.pm is little more than a class loader. It implements some magic to cut down on the setup\nwork.\n\nParameters to \"use POE\" are not treated as normal imports. Rather, they're abbreviated modules\nto be included along with POE.\n\nuse POE qw(Component::Client::TCP).\n\nAs you can see, the leading \"POE::\" can be omitted this way.\n\nPOE.pm also includes POE::Kernel and POE::Session by default. These two modules are used by\nnearly all POE-based programs. So the above example is actually the equivalent of:\n\nuse POE;\nuse POE::Kernel;\nuse POE::Session;\nuse POE::Component::Client::TCP;\n" }, { "name": "Using POE::Kernel", "content": "POE::Kernel needs to know which event loop you want to use. This is supported in three different\nways:\n\nThe first way is to use an event loop module before using POE::Kernel (or POE, which loads\nPOE::Kernel for you):\n\nuse Tk; # or one of several others\nuse POE::Kernel.\n\nPOE::Kernel scans the list of modules already loaded, and it loads an appropriate POE::Loop\nadapter if it finds a known event loop.\n\nThe next way is to explicitly load the POE::Loop class you want:\n\nuse POE qw(Loop::Gtk);\n\nFinally POE::Kernel's \"import()\" supports more programmer-friendly configuration:\n\nuse POE::Kernel { loop => \"Gtk\" };\nuse POE::Session;\n" }, { "name": "Anatomy of a POE-Based Application", "content": "Programs using POE work like any other. They load required modules, perform some setup, run some\ncode, and eventually exit. Halting Problem notwithstanding.\n\nA POE-based application loads some modules, sets up one or more sessions, runs the code in those\nsessions, and eventually exits.\n\nuse POE;\nPOE::Session->create( ... map events to code here ... );\nPOE::Kernel->run();\nexit;\n\nPOE::Kernel singleton\nThe POE::Kernel is a singleton object; there can be only one POE::Kernel instance within a\nprocess. This allows many object methods to also be package methods.\n" }, { "name": "Sessions", "content": "POE implements isolated compartments called *sessions*. Sessions play the role of tasks or\nthreads within POE. POE::Kernel acts as POE's task scheduler, doling out timeslices to each\nsession by invoking callbacks within them.\n\nCallbacks are not preemptive. As long as one is running, no others will be dispatched. This is\nknown as *cooperative* multitasking. Each session must cooperate by returning to the central\ndispatching kernel.\n\nCooperative multitasking vastly simplifies data sharing, since no two pieces of code may alter\ndata at once.\n\nA session may also take exclusive control of a program's time, if necessary, by simply not\nreturning in a timely fashion. It's even possible to write completely blocking programs that use\nPOE as a state machine rather than a cooperative dispatcher.\n\nEvery POE-based application needs at least one session. Code cannot run *within POE* without\nbeing a part of some session. Likewise, a threaded program always has a \"thread zero\".\n\nSessions in POE::Kernel should not be confused with POE::Session even though the two are\ninextricably associated. POE::Session adapts POE::Kernel's dispatcher to a particular calling\nconvention. Other POE::Session classes exist on the CPAN. Some radically alter the way event\nhandlers are called. .\n" }, { "name": "Resources", "content": "Resources are events and things which may create new events, such as timers, I/O watchers, and\neven other sessions.\n\nPOE::Kernel tracks resources on behalf of its active sessions. It generates events corresponding\nto these resources' activity, notifying sessions when it's time to do things.\n\nThe conversation goes something like this:\n\nSession: Be a dear, Kernel, and let me know when someone clicks on\nthis widget. Thanks so much!\n\n[TIME PASSES] [SFX: MOUSE CLICK]\n\nKernel: Right, then. Someone's clicked on your widget.\nHere you go.\n\nFurthermore, since the Kernel keeps track of everything sessions do, it knows when a session has\nrun out of tasks to perform. When this happens, the Kernel emits a \"stop\" event at the dead\nsession so it can clean up and shutdown.\n\nKernel: Please switch off the lights and lock up; it's time to go.\n\nLikewise, if a session stops on its own and there still are opened resource watchers, the Kernel\nknows about them and cleans them up on the session's behalf. POE excels at long-running services\nbecause it so meticulously tracks and cleans up resources.\n\nPOE::Resources and the POE::Resource classes implement each kind of resource, which are\nsummarized here and covered in greater detail later.\n\nEvents.\nAn event is a message to a sessions. Posting an event keeps both the sender and the receiver\nalive until after the event has been dispatched. This is only guaranteed if both the sender\nand receiver are in the same process. Inter-Kernel message passing add-ons may have other\nguarantees. Please see their documentation for details.\n\nThe rationale is that the event is in play, so the receiver must remain active for it to be\ndispatched. The sender remains alive in case the receiver would like to send back a response.\n\nPosted events cannot be preemptively canceled. They tend to be short-lived in practice, so\nthis generally isn't an issue.\n\nTimers.\nTimers allow an application to send a message to the future. Once set, a timer will keep the\ndestination session active until it goes off and the resulting event is dispatched.\n\nAliases.\nSession aliases are an application-controlled way of addressing a session. Aliases act as\npassive event watchers. As long as a session has an alias, some other session may send events\nto that session by that name. Aliases keep sessions alive as long as a process has active\nsessions.\n\nIf the only sessions remaining are being kept alive solely by their aliases, POE::Kernel will\nsend them a terminal \"IDLE\" signal. In most cases this will terminate the remaining sessions\nand allow the program to exit. If the sessions remain in memory without waking up on the\n\"IDLE\" signal, POE::Kernel sends them a non-maskable \"ZOMBIE\" signal. They are then forcibly\nremoved, and the program will finally exit.\n\nI/O watchers.\nA session will remain active as long as a session is paying attention to some external data\nsource or sink. See selectread and selectwrite.\n\nChild sessions.\nA session acting as a parent of one or more other sessions will remain active until all the\nchild sessions stop. This may be bypassed by detaching the children from the parent.\n\nChild processes.\nChild process are watched by sigchild(). The sigchild() watcher will keep the watching\nsession active until the child process has been reaped by POE::Kernel and the resulting event\nhas been dispatched.\n\nAll other signal watchers, including using \"sig\" to watch for \"CHLD\", do not keep their\nsessions active. If you need a session to remain active when it's only watching for signals,\nhave it set an alias or one of its own public reference counters.\n\nPublic reference counters.\nA session will remain active as long as it has one or more nonzero public (or external)\nreference counter.\n" }, { "name": "Session Lifespans", "content": "\"Session\" as a term is somewhat overloaded. There are two related concepts that share the name.\nFirst there is the class POE::Session, and objects created with it or related classes. Second\nthere is a data structure within POE::Kernel that tracks the POE::Session objects in play and\nthe various resources owned by each.\n\nThe way POE's garbage collector works is that a session object gives itself to POE::Kernel at\ncreation time. The Kernel then holds onto that object as long as resources exist that require\nthe session to remain alive. When all of these resources are destroyed or released, the session\nobject has nothing left to trigger activity. POE::Kernel notifies the object it's through, and\ncleans up its internal session context. The session object is released, and self-destructs in\nthe normal Perlish fashion.\n\nSessions may be stopped even if they have active resources. For example, a session may fail to\nhandle a terminal signal. In this case, POE::Kernel forces the session to stop, and all\nresources associated with the session are preemptively released.\n" }, { "name": "Events", "content": "An event is a message that is sent from one part of the POE application to another. An event\nconsists of the event's name, optional event-specific parameters and OOB information. An event\nmay be sent from the kernel, from a wheel or from a session.\n\nAn application creates an event with \"post\", \"yield\", \"call\" or even \"signal\". POE::Kernel\ncreates events in response external stimulus (signals, select, etc).\n\nEvent Handlers\nAn event is handled by a function called an *event handler*, which is some code that is\ndesignated to be called when a particular event is dispatched. See \"Event Handler Management\"\nand POE::Session.\n\nThe term *state* is often used in place of *event handler*, especially when treating sessions as\nevent driven state machines.\n\nHandlers are always called in scalar context for asynchronous events (i.e. via post()).\nSynchronous events, invoked with call(), are handled in the same context that call() was called.\n\nEvent handlers may not directly return references to objects in the \"POE\" namespace. POE::Kernel\nwill stringify these references to prevent timing issues with certain objects' destruction. For\nexample, this error handler would cause errors because a deleted wheel would not be destructed\nwhen one might think:\n\nsub handleerror {\nwarn \"Got an error\";\ndelete $[HEAP]{wheel};\n}\n\nThe delete() call returns the deleted wheel member, which is then returned implicitly by" }, { "name": "handle_error", "content": "" }, { "name": "Using POE with Other Event Loops", "content": "POE::Kernel supports any number of event loops. Two are included in the base distribution.\nHistorically, POE included other loops but they were moved into a separate distribution. You can\nfind them and other loops on the CPAN.\n\nPOE's public interfaces remain the same regardless of the event loop being used. Since most\ngraphical toolkits include some form of event loop, back-end code should be portable to all of\nthem.\n\nPOE's cooperation with other event loops lets POE be embedded into other software. The common\nunderlying event loop drives both the application and POE. For example, by using\nPOE::Loop::Glib, one can embed POE into Vim, irssi, and so on. Application scripts can then take\nadvantage of POE::Component::Client::HTTP (and everything else) to do large-scale work without\nblocking the rest of the program.\n\nBecause this is Perl, there are multiple ways to load an alternate event loop. The simplest way\nis to load the event loop before loading POE::Kernel.\n\nuse Gtk;\nuse POE;\n\nRemember that POE loads POE::Kernel internally.\n\nPOE::Kernel examines the modules loaded before it and detects that Gtk has been loaded. If\nPOE::Loop::Gtk is available, POE loads and hooks it into POE::Kernel automatically.\n\nIt's less mysterious to load the appropriate POE::Loop class directly. Their names follow the\nformat \"POE::Loop::$loopmodulename\", where $loopmodulename is the name of the event loop\nmodule after each \"::\" has been substituted with an underscore. It can be abbreviated using\nPOE's loader magic.\n\nuse POE qw( Loop::EventLib );\n\nPOE also recognizes XS loops, they reside in the \"POE::XS::Loop::$loopmodulename\" namespace.\nUsing them may give you a performance improvement on your platform, as the eventloop are some of\nthe hottest code in the system. As always, benchmark your application against various loops to\nsee which one is best for your workload and platform.\n\nuse POE qw( XS::Loop::EPoll );\n\nPlease don't load the loop modules directly, because POE will not have a chance to initialize\nit's internal structures yet. Code written like this will throw errors on startup. It might look\nlike a bug in POE, but it's just the way POE is designed.\n\nuse POE::Loop::IOPoll;\nuse POE;\n\nPOE::Kernel also supports configuration directives on its own \"use\" line. A loop explicitly\nspecified this way will override the search logic.\n\nuse POE::Kernel { loop => \"Glib\" };\n\nFinally, one may specify the loop class by setting the POE::Loop or POE::XS:Loop class name in\nthe POEEVENTLOOP environment variable. This mechanism was added for tests that need to specify\nthe loop from a distance.\n\nBEGIN { $ENV{POEEVENTLOOP} = \"POE::XS::Loop::Poll\" }\nuse POE;\n\nOf course this may also be set from your shell:\n\n% export POEEVENTLOOP='POE::XS::Loop::Poll'\n% make test\n\nMany external event loops support their own callback mechanisms. POE::Session's \"postback()\" and\n\"callback()\" methods return plain Perl code references that will generate POE events when\ncalled. Applications can pass these code references to event loops for use as callbacks.\n\nPOE's distribution includes two event loop interfaces. CPAN holds several more:\n\nPOE::Loop::Select (bundled)\nBy default POE uses its select() based loop to drive its event system. This is perhaps the least\nefficient loop, but it is also the most portable. POE optimizes for correctness above all.\n\nPOE::Loop::IOPoll (bundled)\nThe IO::Poll event loop provides an alternative that theoretically scales better than select().\n\nPOE::Loop::Event (separate distribution)\nThis event loop provides interoperability with other modules that use Event. It may also provide\na performance boost because Event is written in a compiled language. Unfortunately, this makes\nEvent less portable than Perl's built-in select().\n\nPOE::Loop::Gtk (separate distribution)\nThis event loop allows programs to work under the Gtk graphical toolkit.\n\nPOE::Loop::Tk (separate distribution)\nThis event loop allows programs to work under the Tk graphical toolkit. Tk has some restrictions\nthat require POE to behave oddly.\n\nTk's event loop will not run unless one or more widgets are created. POE must therefore create\nsuch a widget before it can run. POE::Kernel exports $poemainwindow so that the application\ndeveloper may use the widget (which is a MainWindow), since POE doesn't need it other than for\ndispatching events.\n\nCreating and using a different MainWindow often has an undesired outcome.\n\nPOE::Loop::EV (separate distribution)\nPOE::Loop::EV allows POE-based programs to use the EV event library with little or no change.\n\nPOE::Loop::Glib (separate distribution)\nPOE::Loop::Glib allows POE-based programs to use Glib with little or no change. It also supports\nembedding POE-based programs into applications that already use Glib. For example, we have heard\nthat POE has successfully embedded into vim, irssi and xchat via this loop.\n\nPOE::Loop::Kqueue (separate distribution)\nPOE::Loop::Kqueue allows POE-based programs to transparently use the BSD kqueue event library on\noperating systems that support it.\n\nPOE::Loop::Prima (separate distribution)\nPOE::Loop::Prima allows POE-based programs to use Prima's event loop with little or no change.\nIt allows POE libraries to be used within Prima applications.\n\nPOE::Loop::Wx (separate distribution)\nPOE::Loop::Wx allows POE-based programs to use Wx's event loop with little or no change. It\nallows POE libraries to be used within Wx applications, such as Padre.\n\nPOE::XS::Loop::EPoll (separate distribution)\nPOE::XS::Loop::EPoll allows POE components to transparently use the EPoll event library on\noperating systems that support it.\n\nPOE::XS::Loop::Poll (separate distribution)\nPOE::XS::Loop::Poll is a higher-performance C-based libpoll event loop. It replaces some of\nPOE's hot Perl code with C for better performance.\n\nOther Event Loops (separate distributions)\nPOE may be extended to handle other event loops. Developers are invited to work with us to\nsupport their favorite loops.\n" } ] }, "PUBLIC METHODS": { "content": "POE::Kernel encapsulates a lot of features. The documentation for each set of features is\ngrouped by purpose.\n", "subsections": [ { "name": "Kernel Management and Accessors", "content": "ID\nID() currently returns POE::Kernel's unique identifier. Every Kernel instance is assigned a\nglobally unique ID at birth. hasforked() alters the ID so that each forked process has a unique\none, too.\n\n% perl -wl -MPOE -e 'print $poekernel->ID'\nmacbookpoe.local-4d5305de-0000e6b8-00000001\n\nThe content of these IDs may change from time to time. Your code should not depend upon the\ncurrent format.\n\nDeprecation Warning 2011-02-09\n\nYour code should not depend upon ID() remaining unique. The uniqueness will be removed in a\nfuture release of POE. If you require unique IDs, please see one of the fine GUID and/or UUID\nmodules on the CPAN:\n\nhttp://search.cpan.org/search?query=GUID&mode=dist\nhttp://search.cpan.org/search?query=UUID&mode=dist\n\nPOE doesn't require globally or universally unique kernel IDs. The creation and maintenance of\nthese IDs adds overhead to POE::Kernel's hasforked() method. Other modules do it better, upon\ndemand, without incurring overhead for those who don't need them.\n\nrun" }, { "name": "run", "content": "" }, { "name": "run", "content": "use POE;\nPOE::Session->create( ... ); # one or more\nPOE::Kernel->run(); # set them all running\nexit;\n\nPOE implements the Reactor pattern at its core. Events are dispatched to functions and methods\nthrough callbacks. The code behind run() waits for and dispatches events.\n" }, { "name": "run", "content": "while run() was running.\n\nPOE::Kernel will print a strong message if a program creates sessions but fails to call run().\nPrior to this warning, we received tons of bug reports along the lines of \"my POE program isn't\ndoing anything\". It turned out that people forgot to start an event dispatcher, so events were\nnever dispatched.\n\nIf the lack of a run() call is deliberate, perhaps because some other event loop already has\ncontrol, you can avoid the message by calling it before creating a session. run() at that point\nwill initialize POE and return immediately. POE::Kernel will be satisfied that run() was called,\nalthough POE will not have actually taken control of the event loop.\n\nuse POE;\nPOE::Kernel->run(); # silence the warning\nPOE::Session->create( ... );\nexit;\n\nNote, however, that this varies from one event loop to another. If a particular POE::Loop\nimplementation doesn't support it, that's probably a bug. Please file a bug report with the\nowner of the relevant POE::Loop module.\n\nrunonetimeslice" }, { "name": "run_one_timeslice", "content": "timers that are due, asynchronous messages that need to be delivered, signals that require\nhandling, and notifications for files with pending I/O. Do not rely too much on event ordering." }, { "name": "run_one_timeslice", "content": "" }, { "name": "run", "content": "runonetimeslice() while $sessioncount > 0;\n" }, { "name": "run_one_timeslice", "content": "blocking behavior. The pattern is implemented with a flag that is set when some asynchronous\nevent occurs. A loop calls runonetimeslice() until that flag is set. For example:\n\nmy $done = 0;\n\nsub handlesomeevent {\n$done = 1;\n}\n\n$kernel->runonetimeslice() while not $done;\n\nDo be careful. The above example will spin if POE::Kernel is done but $done is never set. The\nloop will never be done, even though there's nothing left that will set $done.\n\nrunwhile SCALARREF" }, { "name": "run_while", "content": "are no more active sessions, or the value of the referenced scalar becomes false.\n\nHere's a version of the runonetimeslice() example using runwhile() instead:\n\nmy $jobcount = 3;\n\nsub handlesomeevent {\n$jobcount--;\n}\n\n$kernel->runwhile(\\$jobcount);\n\nhasforked\nmy $pid = fork();\ndie \"Unable to fork\" unless defined $pid;\nunless( $pid ) {\n$poekernel->hasforked;\n}\n\nInform the kernel that it is now running in a new process. This allows the kernel to reset some\ninternal data to adjust to the new situation.\n" }, { "name": "has_forked", "content": "you want the child process to have new kernel, you must call \"stop\" instead.\n\nNote: POE's internals will detect if a fork occurred before \"run()\" and will call \"hasforked()\"\nautomatically. If you are unsure whether you need to call it or not, please enable\n\"ASSERTUSAGE\" and POE will emit a warning if it's necessary.\n\nstop" }, { "name": "stop", "content": "freeing all used resources, and stopping every active session. stop() is not meant to be used\nlightly. Proceed with caution.\n\nCaveats:\n\nThe session that calls stop() will not be fully DESTROYed until it returns. Invoking an event\nhandler in the session requires a reference to that session, and weak references are prohibited\nin POE for backward compatibility reasons, so it makes sense that the last session won't be\ngarbage collected right away.\n\nSessions are not notified about their destruction. If anything relies on stop being delivered,\nit will break and/or leak memory.\n" }, { "name": "stop", "content": "POE::Wheel::Run. If it proves unfixably problematic, it will be removed without much notice.\n" }, { "name": "stop", "content": "its source.\n\nSee \"Running POE::Kernel in the Child\" in POE::Wheel::Run for an example of how to use this\nfacility.\n\nAsynchronous Messages (FIFO Events)\nAsynchronous messages are events that are dispatched in the order in which they were enqueued\n(the first one in is the first one out, otherwise known as first-in/first-out, or FIFO order).\nThese methods enqueue new messages for delivery. The act of enqueuing a message keeps the sender\nalive at least until the message is delivered.\n\npost DESTINATION, EVENTNAME [, PARAMETERLIST]" }, { "name": "post", "content": "be handled by the code associated with EVENTNAME. If a PARAMETERLIST is included, its values\nwill also be passed along.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->post( $[SESSION], \"eventname\", 0 );\n},\neventname => sub {\nprint \"$[ARG0]\\n\";\n$[KERNEL]->post( $[SESSION], \"eventname\", $[ARG0] + 1 );\n},\n}\n);\n" }, { "name": "post", "content": "" }, { "name": "post", "content": "ESRCH (\"No such process\") - The DESTINATION session did not exist at the time post() was called.\n\nyield EVENTNAME [, PARAMETERLIST]\nyield() is a shortcut for post() where the destination session is the same as the sender. This\nexample is equivalent to the one for post():\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->yield( \"eventname\", 0 );\n},\neventname => sub {\nprint \"$[ARG0]\\n\";\n$[KERNEL]->yield( \"eventname\", $[ARG0] + 1 );\n},\n}\n);\n\nAs with post(), yield() returns right away, and the enqueued EVENTNAME is dispatched later.\nThis may be confusing if you're already familiar with threading.\n\nyield() should always succeed, so it does not return a meaningful value.\n" }, { "name": "Synchronous Messages", "content": "It is sometimes necessary for code to be invoked right away. For example, some resources must be\nserviced right away, or they'll faithfully continue reporting their readiness. These reports\nwould appear as a stream of duplicate events. Synchronous events can also prevent data from\ngoing stale between the time an event is enqueued and the time it's delivered.\n\nSynchronous event handlers preempt POE's event queue, so they should perform simple tasks of\nlimited duration. Synchronous events that need to do more than just service a resource should\npass the resource's information to an asynchronous handler. Otherwise synchronous operations\nwill occur out of order in relation to asynchronous events. It's very easy to have race\nconditions or break causality this way, so try to avoid it unless you're okay with the\nconsequences.\n\nPOE provides these ways to call message handlers right away.\n\ncall DESTINATION, EVENTNAME [, PARAMETERLIST]" }, { "name": "call", "content": "associated with an EVENTNAME. An optional PARAMETERLIST will be passed along to the message's\nhandler. The difference, however, is that the handler will be invoked immediately, even before" }, { "name": "call", "content": "" }, { "name": "call", "content": "is invoked before call() returns. call() can therefore be used as an accessor, although there\nare better ways to accomplish simple accessor behavior.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\nprint \"Got: \", $[KERNEL]->call($[SESSION], \"donow\"), \"\\n\";\n},\ndonow => sub {\nreturn \"some value\";\n}\n}\n);\n\nThe POE::Wheel classes uses call() to synchronously deliver I/O notifications. This avoids a\nhost of race conditions.\n" }, { "name": "call", "content": "some nonzero value indicating why. Since call() may return undef as a matter of course, it's\nrecommended that $! be checked for the error condition as well as the explanation.\n\nESRCH (\"No such process\") - The DESTINATION session did not exist at the time post() was called.\n\nTimer Events (Delayed Messages)\nIt's often useful to wait for a certain time or until a certain amount of time has passed. POE\nsupports this with events that are deferred until either an absolute time (\"alarms\") or until a\ncertain duration of time has elapsed (\"delays\").\n\nTimer interfaces are further divided into two groups. One group identifies timers by the names\nof their associated events. Another group identifies timers by a unique identifier returned by\nthe timer constructors. Technically, the two are both name-based, but the \"identifier-based\"\ntimers provide a second, more specific handle to identify individual timers.\n\nTimers may only be set up for the current session. This design was modeled after alarm() and\nSIGALRM, which only affect the current UNIX process. Each session has a separate namespace for\ntimer names. Timer methods called in one session cannot affect the timers in another. As you may\nhave noticed, quite a lot of POE's API is designed to prevent sessions from interfering with\neach other.\n\nThe best way to simulate deferred inter-session messages is to send an immediate message that\ncauses the destination to set a timer. The destination's timer then defers the action requested\nof it. This way is preferred because the time spent communicating the request between sessions\nmay not be trivial, especially if the sessions are separated by a network. The destination can\ndetermine how much time remains on the requested timer and adjust its wait time accordingly.\n\nName-Based Timers\nName-based timers are identified by the event names used to set them. It is possible for\ndifferent sessions to use the same timer event names, since each session is a separate\ncompartment with its own timer namespace. It is possible for a session to have multiple timers\nfor a given event, but results may be surprising. Be careful to use the right timer methods.\n\nThe name-based timer methods are alarm(), alarmadd(), delay(), and delayadd().\n\nalarm EVENTNAME [, EPOCHTIME [, PARAMETERLIST] ]" }, { "name": "alarm", "content": "a new timer, named EVENTNAME, that will fire EVENTNAME at the current session when EPOCHTIME\nhas been reached. An optional PARAMETERLIST may be passed along to the timer's handler.\n\nOmitting the EPOCHTIME and subsequent parameters causes alarm() to clear the EVENTNAME timers\nin the current session without setting a new one.\n\nEPOCHTIME is the UNIX epoch time. You know, seconds since midnight, 1970-01-01. POE uses\nTime::HiRes::time(), which allows EPOCHTIME to be (or include) fractional seconds.\n\nPOE supports fractional seconds, but accuracy falls off steeply after 1/100 second. Mileage will\nvary depending on your CPU speed and your OS time resolution.\n\nBe sure to use Time::HiRes::time() rather than Perl's built-in time() if sub-second accuracy\nmatters at all. The built-in time() returns floor(Time::HiRes::time()), which is nearly always\nsome fraction of a second in the past. For example the high-resolution time might be\n1200941422.89996. At that same instant, time() would be 1200941422. An alarm for time() + 0.5\nwould be 0.39996 seconds in the past, so it would be dispatched immediately (if not sooner).\n\nPOE's event queue is time-ordered, so a timer due before time() will be delivered ahead of other\nevents but not before timers with even earlier due times. Therefore an alarm() with an\nEPOCHTIME before time() jumps ahead of the queue.\n\nAll timers are implemented identically internally, regardless of how they are set. alarm() will\ntherefore blithely clear timers set by other means.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->alarm( tick => time() + 1, 0 );\n},\ntick => sub {\nprint \"tick $[ARG0]\\n\";\n$[KERNEL]->alarm( tock => time() + 1, $[ARG0] + 1 );\n},\ntock => sub {\nprint \"tock $[ARG0]\\n\";\n$[KERNEL]->alarm( tick => time() + 1, $[ARG0] + 1 );\n},\n}\n);\n" }, { "name": "alarm", "content": "parameter, such as an undefined EVENTNAME.\n\nalarmadd EVENTNAME, EPOCHTIME [, PARAMETERLIST]" }, { "name": "alarm_add", "content": "EPOCHTIME is a required parameter. Otherwise the semantics are identical to alarm().\n\nA program may use alarmadd() without first using alarm().\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->alarmadd( tick => time() + 1.0, 1000000 );\n$[KERNEL]->alarmadd( tick => time() + 1.5, 2000000 );\n},\ntick => sub {\nprint \"tick $[ARG0]\\n\";\n$[KERNEL]->alarmadd( tock => time() + 1, $[ARG0] + 1 );\n},\ntock => sub {\nprint \"tock $[ARG0]\\n\";\n$[KERNEL]->alarmadd( tick => time() + 1, $[ARG0] + 1 );\n},\n}\n);\n" }, { "name": "alarm_add", "content": "delay EVENTNAME [, DURATIONSECONDS [, PARAMETERLIST] ]" }, { "name": "delay", "content": "a new timer, named EVENTNAME, that will fire EVENTNAME at the current session when\nDURATIONSECONDS have elapsed from \"now\". An optional PARAMETERLIST may be passed along to the\ntimer's handler.\n\nOmitting the DURATIONSECONDS and subsequent parameters causes delay() to clear the EVENTNAME\ntimers in the current session without setting a new one.\n\nDURATIONSECONDS may be or include fractional seconds. As with all of POE's timers, accuracy\nfalls off steeply after 1/100 second. Mileage will vary depending on your CPU speed and your OS\ntime resolution.\n\nPOE's event queue is time-ordered, so a timer due before time() will be delivered ahead of other\nevents but not before timers with even earlier due times. Therefore a delay () with a zero or\nnegative DURATIONSECONDS jumps ahead of the queue.\n" }, { "name": "delay", "content": "timing issues. This code is roughly equivalent to the alarm() example.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->delay( tick => 1, 0 );\n},\ntick => sub {\nprint \"tick $[ARG0]\\n\";\n$[KERNEL]->delay( tock => 1, $[ARG0] + 1 );\n},\ntock => sub {\nprint \"tock $[ARG0]\\n\";\n$[KERNEL]->delay( tick => 1, $[ARG0] + 1 );\n},\n}\n);\n" }, { "name": "delay", "content": "delayadd EVENTNAME, DURATIONSECONDS [, PARAMETERLIST]" }, { "name": "delay_add", "content": "DURATIONSECONDS is a required parameter. Otherwise the semantics are identical to delay().\n\nA program may use delayadd() without first using delay().\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->delayadd( tick => 1.0, 1000000 );\n$[KERNEL]->delayadd( tick => 1.5, 2000000 );\n},\ntick => sub {\nprint \"tick $[ARG0]\\n\";\n$[KERNEL]->delayadd( tock => 1, $[ARG0] + 1 );\n},\ntock => sub {\nprint \"tock $[ARG0]\\n\";\n$[KERNEL]->delayadd( tick => 1, $[ARG0] + 1 );\n},\n}\n);\n" }, { "name": "delay_add", "content": "Identifier-Based Timers\nA second way to manage timers is through identifiers. Setting an alarm or delay with the\n\"identifier\" methods allows a program to manipulate several timers with the same name in the\nsame session. As covered in alarm() and delay() however, it's possible to mix named and\nidentified timer calls, but the consequences may not always be expected.\n\nalarmset EVENTNAME, EPOCHTIME [, PARAMETERLIST]" }, { "name": "alarm_set", "content": "the alarm later. Unlike alarm(), it does not first clear existing timers with the same\nEVENTNAME. Otherwise the semantics are identical to alarm().\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[HEAP]{alarmid} = $[KERNEL]->alarmset(\nparty => time() + 1999\n);\n$[KERNEL]->delay(raid => 1);\n},\nraid => sub {\n$[KERNEL]->alarmremove( delete $[HEAP]{alarmid} );\n},\n}\n);\n" }, { "name": "alarm_set", "content": "EVENTNAME or TIME is undefined.\n\nalarmadjust ALARMID, DELTASECONDS" }, { "name": "alarm_adjust", "content": "negative. It may even be zero, but that's not as useful. On success, it returns the timer's new\ndue time since the start of the UNIX epoch.\n\nIt's possible to alarmadjust() timers created by delayset() as well as alarmset().\n\nThis example moves an alarm's due time ten seconds earlier.\n\nuse POSIX qw(strftime);\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[HEAP]{alarmid} = $[KERNEL]->alarmset(\nparty => time() + 1999\n);\n$[KERNEL]->delay(postpone => 1);\n},\npostpone => sub {\nmy $newtime = $[KERNEL]->alarmadjust(\n$[HEAP]{alarmid}, -10\n);\nprint(\n\"Now we're gonna party like it's \",\nstrftime(\"%F %T\", gmtime($newtime)), \"\\n\"\n);\n},\n}\n);\n" }, { "name": "alarm_adjust", "content": "if ALARMID or DELTASECONDS are undefined. It may be ESRCH if ALARMID no longer refers to a\npending timer. $! may also contain EPERM if ALARMID is valid but belongs to a different\nsession.\n\nalarmremove ALARMID" }, { "name": "alarm_remove", "content": "" }, { "name": "alarm_set", "content": "Upon success, alarmremove() returns something true based on its context. In a list context, it\nreturns three things: The removed alarm's event name, the UNIX time it was due to go off, and a\nreference to the PARAMETERLIST (if any) assigned to the timer when it was created. If\nnecessary, the timer can be re-set with this information.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[HEAP]{alarmid} = $[KERNEL]->alarmset(\nparty => time() + 1999\n);\n$[KERNEL]->delay(raid => 1);\n},\nraid => sub {\nmy ($name, $time, $param) = $[KERNEL]->alarmremove(\n$[HEAP]{alarmid}\n);\nprint(\n\"Removed alarm for event $name due at $time with @$param\\n\"\n);\n\n# Or reset it, if you'd like. Possibly after modification.\n$[KERNEL]->alarmset($name, $time, @$param);\n},\n}\n);\n\nIn a scalar context, it returns a reference to a list of the three things above.\n\n# Remove and reset an alarm.\nmy $alarminfo = $[KERNEL]->alarmremove( $alarmid );\nmy $newid = $[KERNEL]->alarmset(\n$alarminfo[0], $alarminfo[1], @{$alarminfo[2]}\n);\n\nUpon failure, however, alarmremove() returns a Boolean false value and sets $! with the reason\nwhy the call failed:\n\nEINVAL (\"Invalid argument\") indicates a problem with one or more parameters, usually an\nundefined ALARMID.\n\nESRCH (\"No such process\") indicates that ALARMID did not refer to a pending alarm.\n\nEPERM (\"Operation not permitted\"). A session cannot remove an alarm it does not own.\n\nalarmremoveall" }, { "name": "alarm_remove_all", "content": "creation method or type. This method takes no arguments. It returns information about the alarms\nthat were removed, either as a list of alarms or a list reference depending whether" }, { "name": "alarm_remove_all", "content": "Each removed alarm's information is identical to the format explained in alarmremove().\n\nsub someeventhandler {\nmy @removedalarms = $[KERNEL]->alarmremoveall();\nforeach my $alarm (@removedalarms) {\nmy ($name, $time, $param) = @$alarm;\n...;\n}\n}\n\ndelayset EVENTNAME, DURATIONSECONDS [, PARAMETERLIST]" }, { "name": "delay_set", "content": "code associated with EVENTNAME in the current session. An optional PARAMETERLIST will be\npassed through to the handler. It returns the same sort of things that alarmset() does.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->delayset(\"later\", 5, \"hello\", \"world\");\n},\nlater => sub {\nprint \"@[ARG0..#$]\\n\";\n}\n}\n);\n\ndelayadjust ALARMID, SECONDSFROMNOW" }, { "name": "delay_adjust", "content": "watchdog- or timeout-style timers. On success it returns the new absolute UNIX time the timer\nwill be due.\n\nIt's possible for delayadjust() to adjust timers created by alarmset() as well as delayset().\n\nuse POSIX qw(strftime);\n\nPOE::Session->create(\ninlinestates => {\n# Setup.\n# ... omitted.\n\ngotinput => sub {\nmy $newtime = $[KERNEL]->delayadjust(\n$[HEAP]{inputtimeout}, 60\n);\nprint(\n\"Refreshed the input timeout. Next may occur at \",\nstrftime(\"%F %T\", gmtime($newtime)), \"\\n\"\n);\n},\n}\n);\n\nOn failure it returns Boolean false and sets $! to a reason for the failure. See the explanation\nof $! for alarmadjust().\n\ndelayremove is not needed\nThere is no delayremove(). Timers are all identical internally, so alarmremove() will work\nwith timer IDs returned by delayset().\n\ndelayremoveall is not needed\nThere is no delayremoveall(). Timers are all identical internally, so alarmremoveall()\nclears them all regardless how they were created.\n\nComparison\nBelow is a table to help compare the various delayed message-sending methods\n\n+-----------+------------------+---------------------+------------+\n| | time argument | clears other events | returns on |\n| method | passed to method | of the same name | success |\n+-----------+------------------+---------------------+------------+\n| delayset | seconds from now | N | alarmid |\n| delay | seconds from now | Y | 0 (false) |\n| alarmset | unix epoch time | N | alarmid |\n| alarm | unix epoch time | Y | 0 (false) |\n+-----------+------------------+---------------------+------------+\n\nSession Identifiers (IDs and Aliases)\nA session may be referred to by its object references (either blessed or stringified), a session\nID, or one or more symbolic names we call aliases.\n\nEvery session is represented by an object, so session references are fairly straightforward.\nPOE::Kernel may reference these objects. For instance, post() may use $[SENDER] as a\ndestination:\n\nPOE::Session->create(\ninlinestates => {\nstart => sub { $[KERNEL]->aliasset(\"echoer\") },\nping => sub {\n$[KERNEL]->post( $[SENDER], \"pong\", @[ARG0..$#] );\n}\n}\n);\n\nPOE also recognized stringified Session objects for convenience and as a form of weak reference.\nHere $[SENDER] is wrapped in quotes to stringify it:\n\nPOE::Session->create(\ninlinestates => {\nstart => sub { $[KERNEL]->aliasset(\"echoer\") },\nping => sub {\n$[KERNEL]->post( \"$[SENDER]\", \"pong\", @[ARG0..$#] );\n}\n}\n);\n\nEvery session is assigned a unique ID at creation time. No two active sessions will have the\nsame ID, but IDs may be reused over time. The combination of a kernel ID and a session ID should\nbe sufficient as a global unique identifier.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub { $[KERNEL]->aliasset(\"echoer\") },\nping => sub {\n$[KERNEL]->delay(\nponglater => rand(5), $[SENDER]->ID, @[ARG0..$#]\n);\n},\nponglater => sub {\n$[KERNEL]->post( $[ARG0], \"pong\", @[ARG1..$#] );\n}\n}\n);\n\nKernels also maintain a global session namespace or dictionary from which may be used to map a\nsymbolic aliases to a session. Once an alias is mapping has been created, that alias may be used\nto refer to the session wherever a session may be specified.\n\nIn the previous examples, each echoer service has set an \"echoer\" alias. Another session can\npost a ping request to the echoer session by using that alias rather than a session object or\nID. For example:\n\nPOE::Session->create(\ninlinestates => {\nstart => sub { $[KERNEL]->post(echoer => ping => \"whee!\" ) },\npong => sub { print \"@[ARG0..$#]\\n\" }\n}\n);\n\nA session with an alias will not stop until all other activity has stopped. Aliases are treated\nas a kind of event watcher. Events come from active sessions. Aliases therefore become useless\nwhen there are no active sessions left. Rather than leaving the program running in a \"zombie\"\nstate, POE detects this deadlock condition and triggers a cleanup. See \"Signal Classes\" for more\ninformation.\n\naliasset ALIAS" }, { "name": "alias_set", "content": "be used nearly everywhere a session reference, stringified reference, or ID is expected.\n\nSessions may have more than one alias. Each alias must be defined in a separate aliasset()\ncall. A single alias may not refer to more than one session.\n\nMultiple alias examples are above.\n" }, { "name": "alias_set", "content": "indicates that the alias is already assigned to to a different session.\n\naliasremove ALIAS" }, { "name": "alias_remove", "content": "will no longer refer to the current session. This does not negatively affect events already\nposted to POE's queue. Alias resolution occurs at post() time, not at delivery time.\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[KERNEL]->aliasset(\"shortwindow\");\n$[KERNEL]->delay(closewindow => 1);\n},\nclosewindow => {\n$[KERNEL]->aliasremove(\"shortwindow\");\n}\n}\n);\n" }, { "name": "alias_remove", "content": "indicates that the ALIAS is not currently in POE::Kernel's dictionary. EPERM (\"Operation not\npermitted\") means that the current session may not remove the ALIAS because it is in use by some\nother session.\n\naliasresolve ALIAS" }, { "name": "alias_resolve", "content": "may be a stringified session reference, a session ID, or an alias previously registered by" }, { "name": "alias_set", "content": "One use for aliasresolve() is to detect whether another session has gone away:\n\nunless (defined $[KERNEL]->aliasresolve(\"Elvis\")) {\nprint \"Elvis has left the building.\\n\";\n}\n\nAs previously mentioned, aliasresolve() returns a session reference or undef on failure.\nFailure also sets $! to ESRCH (\"No such process\") when the ALIAS is not currently in\nPOE::Kernel's.\n\naliaslist [SESSIONREFERENCE]" }, { "name": "alias_list", "content": "session if SESSION is omitted. aliaslist() returns an empty list if the requested SESSION has\nno aliases.\n\nSESSION may be a session reference (blessed or stringified), a session ID, or a session alias.\n\nPOE::Session->create(\ninlinestates => {\n$[KERNEL]->aliasset(\"mi\");\nprint(\n\"The names I call myself: \",\njoin(\", \", $[KERNEL]->aliaslist()),\n\"\\n\"\n);\n}\n);\n\nIDidtosession SESSIONID\nIDidtosession() translates a session ID into a session reference. It's a special-purpose\nsubset of aliasresolve(), so it's a little faster and somewhat less flexible.\n\nunless (defined $[KERNEL]->IDidtosession($sessionid)) {\nprint \"Session $sessionid doesn't exist.\\n\";\n}\n\nIDidtosession() returns undef if a lookup failed. $! will be set to ESRCH (\"No such\nprocess\").\n\nIDsessiontoid SESSIONREFERENCE\nIDsessiontoid() converts a blessed or stringified SESSIONREFERENCE into a session ID. It's\nmore practical for stringified references, as programs can call the POE::Session ID() method on\nthe blessed ones. These statements are equivalent:\n\n$id = $[SENDER]->ID();\n$id = $[KERNEL]->IDsessiontoid($[SENDER]);\n$id = $[KERNEL]->IDsessiontoid(\"$[SENDER]\");\n\nAs with other POE::Kernel lookup methods, IDsessiontoid() returns undef on failure, setting\n$! to ESRCH (\"No such process\").\n\nI/O Watchers (Selects)\nNo event system would be complete without the ability to asynchronously watch for I/O events.\nPOE::Kernel implements the lowest level watchers, which are called \"selects\" because they were\nhistorically implemented using Perl's built-in select(2) function.\n\nApplications handle I/O readiness events by performing some activity on the underlying\nfilehandle. Read-readiness might be handled by reading from the handle. Write-readiness by\nwriting to it.\n\nAll I/O watcher events include two parameters. \"ARG0\" contains the handle that is ready for\nwork. \"ARG1\" contains an integer describing what's ready.\n\nsub handleio {\nmy ($handle, $mode) = @[ARG0, ARG1];\nprint \"File $handle is ready for \";\nif ($mode == 0) {\nprint \"reading\";\n}\nelsif ($mode == 1) {\nprint \"writing\";\n}\nelsif ($mode == 2) {\nprint \"out-of-band reading\";\n}\nelse {\ndie \"unknown mode $mode\";\n}\nprint \"\\n\";\n# ... do something here\n}\n\nThe remaining parameters, @[ARG2..$%], contain additional parameters that were passed to the\nPOE::Kernel method that created the watcher.\n\nPOE::Kernel conditions filehandles to be 8-bit clean and non-blocking. Programs that need them\nconditioned differently should set them up after starting POE I/O watchers. If you are running a\nPerl older than 5.8.1 and is using tied filehandles, you need to set non-blocking mode yourself\nas IO::Handle does not work well. See for\nmore info.\n\nI/O watchers will prevent sessions from stopping.\n\nselectread FILEHANDLE [, EVENTNAME [, ADDITIONALPARAMETERS] ]" }, { "name": "select_read", "content": "FILEHANDLE. The watcher is started if EVENTNAME is specified, or stopped if it's not.\nADDITIONALPARAMETERS, if specified, will be passed to the EVENTNAME handler as @[ARG2..$#].\n\nPOE::Session->create(\ninlinestates => {\nstart => sub {\n$[HEAP]{socket} = IO::Socket::INET->new(\nPeerAddr => \"localhost\",\nPeerPort => 25,\n);\n$[KERNEL]->selectread( $[HEAP]{socket}, \"gotinput\" );\n$[KERNEL]->delay(timedout => 1);\n},\ngotinput => sub {\nmy $socket = $[ARG0];\nwhile (sysread($socket, my $buf = \"\", 8192)) {\nprint $buf;\n}\n},\ntimedout => sub {\n$[KERNEL]->selectread( delete $[HEAP]{socket} );\n},\n}\n);\n" }, { "name": "select_read", "content": "selectwrite FILEHANDLE [, EVENTNAME [, ADDITIONALPARAMETERS] ]" }, { "name": "select_write", "content": "that looks for write-readiness. That is, when EVENTNAME is delivered, it means that FILEHANDLE\nis ready to be written to.\n" }, { "name": "select_write", "content": "selectexpedite FILEHANDLE [, EVENTNAME [, ADDITIONALPARAMETERS] ]" }, { "name": "select_expedite", "content": "watches a FILEHANDLE for out-of-band data ready to be input from a FILEHANDLE. Hardly anybody\nuses this, but it exists for completeness' sake.\n\nAn EVENTNAME event will be delivered whenever the FILEHANDLE can be read from out-of-band.\nOut-of-band data is considered \"expedited\" because it is often ahead of a socket's normal data.\n" }, { "name": "select_expedite", "content": "selectpauseread FILEHANDLE" }, { "name": "select_pause_read", "content": "all the bookkeeping of a selectread(). It's used with selectresumeread() to implement input\nflow control.\n\nInput that occurs on FILEHANDLE will backlog in the operating system buffers until" }, { "name": "select_resume_read", "content": "A side effect of bypassing the selectread() bookkeeping is that a paused FILEHANDLE will not\nprematurely stop the current session.\n" }, { "name": "select_pause_read", "content": "selectresumeread FILEHANDLE" }, { "name": "select_resume_read", "content": "" }, { "name": "select_pause_read", "content": "control.\n\nData backlogged in the operating system due to a selectpauseread() call will become available\nafter selectresumeread() is called.\n" }, { "name": "select_resume_read", "content": "selectpausewrite FILEHANDLE" }, { "name": "select_pause_write", "content": "for input. Please see selectpauseread() for further discussion.\n\nselectresumewrite FILEHANDLE" }, { "name": "select_resume_write", "content": "" }, { "name": "select_resume_read", "content": "select FILEHANDLE [, EVREAD [, EVWRITE [, EVEXPEDITE [, ARGS] ] ] ]\nPOE::Kernel's select() method sets or clears a FILEHANDLE's read, write and expedite watchers\nat once. It's a little more expensive than calling selectread(), selectwrite() and" }, { "name": "select_expedite", "content": "Defined event names enable their corresponding watchers, and undefined event names disable them.\nThis turns off all the watchers for a FILEHANDLE:\n\nsub stopio {\n$[KERNEL]->select( $[HEAP]{filehandle} );\n}\n\nThis statement:\n\n$[KERNEL]->select( $filehandle, undef, \"writeevent\", undef, @stuff );\n\nis equivalent to:\n\n$[KERNEL]->selectread( $filehandle );\n$[KERNEL]->selectwrite( $filehandle, \"writeevent\", @stuff );\n$[KERNEL]->selectexpedite( $filehandle );\n\nPOE::Kernel's select() should not be confused with Perl's built-in select() function.\n\nAs with the other I/O watcher methods, select() does not return a meaningful value.\n" }, { "name": "Session Management", "content": "Sessions are dynamic. They may be created and destroyed during a program's lifespan. When a\nsession is created, it becomes the \"child\" of the current session. The creator -- the current\nsession -- becomes its \"parent\" session. This is loosely modeled after UNIX processes.\n\nThe most common session management is done by creating new sessions and allowing them to\neventually stop.\n\nEvery session has a parent, even the very first session created. Sessions without obvious\nparents are children of the program's POE::Kernel instance.\n\nChild sessions will keep their parents active. See \"Session Lifespans\" for more about why\nsessions stay alive.\n\nThe parent/child relationship tree also governs the way many signals are dispatched. See \"Common\nSignal Dispatching\" for more information on that.\n\nSession Management Events (start, stop, parent, child)\nPOE::Kernel provides four session management events: start, stop, parent and child. They are\ninvoked synchronously whenever a session is newly created or just about to be destroyed.\n\nstart\nstart should be familiar by now. POE dispatches the start event to initialize a session\nafter it has been registered under POE::Kernel. What is not readily apparent, however, is that\nit is invoked before the POE::Session constructor returns.\n\nWithin the start handler, the event's sender is the session that created the new session.\nOtherwise known as the new session's *parent*. Sessions created before POE::Kernel->run() is\ncalled will be descendents of the program's POE::Kernel singleton.\n\nThe start handler's return value is passed to the parent session in a child event, along\nwith the notification that the parent's new child was created successfully. See the discussion\nof child for more details.\n\nPOE::Session->create(\ninlinestates => { start=> \\&start },\nargs => [ $some, $args ]\n);\n\nsub start {\nmy ( $some, $args ) = @[ ARG0, ARG1 ];\n# ....\n}\n\nstop\nstop is a little more mysterious. POE calls a stop handler when a session is irrevocably\nabout to be destroyed. Part of session destruction is the forcible reclamation of its\nresources (events, timers, message events, etc.) so it's not possible to post() a message from\nstop's handler. A program is free to try, but the event will be destroyed before it has a\nchance to be dispatched.\n\nthe stop handler's return value is passed to the parent's child event. See child for more\ndetails.\n\nstop is usually invoked when a session has no further reason to live, although signals may\ncause them to stop sooner.\n\nThe corresponding child handler is invoked synchronously just after stop returns.\n\nparent\nparent is used to notify a child session when its parent has changed. This usually happens\nwhen a session is first created. It can also happen when a child session is detached from its\nparent. See detachchild and \"detachmyself\".\n\nparent's ARG0 contains the session's previous parent, and ARG1 contains its new parent.\n\nsub parent {\nmy ( $oldparent, $newparent ) = @[ ARG0, ARG1 ];\nprint(\n\"Session \", $[SESSION]->ID,\n\" parent changed from session \", $oldparent->ID,\n\" to session \", $newparent->ID,\n\"\\n\"\n);\n}\n\nchild\nchild notifies one session when a child session has been created, destroyed, or reassigned to\nor from another parent. It's usually dispatched when sessions are created or destroyed. It can\nalso happen when a session is detached from its parent.\n\nchild includes some information in the \"arguments\" portion of @. Typically ARG0, ARG1 and\nARG2, but these may be overridden by a different POE::Session class:\n\nARG0 contains a string describing what has happened to the child. The string may be 'create'\n(the child session has been created), 'gain' (the child has been given by another session), or\n'lose' (the child session has stopped or been given away).\n\nIn all cases, ARG1 contains a reference to the child session.\n\nIn the 'create' case, ARG2 holds the value returned by the child session's start handler.\nLikewise, ARG2 holds the stop handler's return value for the 'lose' case.\n\nsub child {\nmy( $reason, $child ) = @[ ARG0, ARG1 ];\nif( $reason eq 'create' ) {\nmy $retval = $[ ARG2 ];\n}\n# ...\n}\n\nThe events are delivered in specific orders.\n\nWhen a new session is created:\n1 The session's constructor is called.\n\n2 The session is put into play. That is, POE::Kernel enters the session into its bookkeeping.\n\n3 The new session receives start.\n\n4 The parent session receives child ('create'), the new session reference, and the new\nsession's start's return value.\n\n5 The session's constructor returns.\n\nWhen an old session stops:\n1 If the session has children of its own, they are given to the session's parent. This\ntriggers one or more child ('gain') events in the parent, and a parent in each child.\n\n2 Once divested of its children, the stopping session receives a stop event.\n\n3 The stopped session's parent receives a child ('lose') event with the departing child's\nreference and stop handler's return value.\n\n4 The stopped session is removed from play, as are all its remaining resources.\n\n5 The parent session is checked for idleness. If so, garbage collection will commence on it,\nand it too will be stopped\n\nWhen a session is detached from its parent:\n1 The parent session of the session being detached is notified with a child ('lose') event.\nThe stop handler's return value is undef since the child is not actually stopping.\n\n2 The detached session is notified with a parent event that its new parent is POE::Kernel\nitself.\n\n3 POE::Kernel's bookkeeping data is adjusted to reflect the change of parentage.\n\n4 The old parent session is checked for idleness. If so, garbage collection will commence on\nit, and it too will be stopped\n\nSession Management Methods\nThese methods allow sessions to be detached from their parents in the rare cases where the\nparent/child relationship gets in the way.\n\ndetachchild CHILDSESSION" }, { "name": "detach_child", "content": "CHILDSESSION will become a child of the POE::Kernel instance, and detachchild() will return\ntrue. On failure however, detachchild() returns false and sets $! to explain the nature of the\nfailure:\n\nESRCH (\"No such process\").\nThe CHILDSESSION is not a valid session.\n\nEPERM (\"Operation not permitted\").\nThe CHILDSESSION exists, but it is not a child of the current session.\n" }, { "name": "detach_child", "content": "Session Management Events for a detailed explanation of these events. See above for the order\nthe events are generated.\n\ndetachmyself" }, { "name": "detach_myself", "content": "running POE::Kernel instance. It returns true on success. On failure it returns false and sets\n$! to explain the nature of the failure:\n\nEPERM (\"Operation not permitted\").\nThe current session is already a child of POE::Kernel, so it may not be detached.\n" }, { "name": "detach_child", "content": "Session Management Events for a detailed explanation of these events. See above for the order\nthe events are generated.\n" }, { "name": "Signals", "content": "POE::Kernel provides methods through which a program can register interest in signals that come\nalong, can deliver its own signals without resorting to system calls, and can indicate that\nsignals have been handled so that default behaviors are not necessary.\n\nSignals are *action at a distance* by nature, and their implementation requires widespread\nsynchronization between sessions (and reentrancy in the dispatcher, but that's an implementation\ndetail). Perfecting the semantics has proven difficult, but POE tries to do the Right Thing\nwhenever possible.\n\nPOE does not register %SIG handlers for signals until sig() is called to watch for them.\nTherefore a signal's default behavior occurs for unhandled signals. That is, SIGINT will\ngracelessly stop a program, SIGWINCH will do nothing, SIGTSTP will pause a program, and so on.\n\nSignal Classes\nThere are three signal classes. Each class defines a default behavior for the signal and whether\nthe default can be overridden. They are:\n\nBenign, advisory, or informative signals\nThese are three names for the same signal class. Signals in this class notify a session of an\nevent but do not terminate the session if they are not handled.\n\nIt is possible for an application to create its own benign signals. See \"signal\" below.\n\nTerminal signals\nTerminal signals will kill sessions if they are not handled by a \"sighandled\"() call. The OS\nsignals that usually kill or dump a process are considered terminal in POE, but they never\ntrigger a coredump. These are: HUP, INT, QUIT and TERM.\n\nThere are two terminal signals created by and used within POE:\n\nDIE \"DIE\" notifies sessions that a Perl exception has occurred. See \"Exception Handling\" for\ndetails.\n\nIDLE\nThe \"IDLE\" signal is used to notify leftover sessions that a program has run out of things\nto do.\n\nNonmaskable signals\nNonmaskable signals are terminal regardless whether sighandled() is called. The term comes from\n\"NMI\", the non-maskable CPU interrupt usually generated by an unrecoverable hardware exception.\n\nSessions that receive a non-maskable signal will unavoidably stop. POE implements two\nnon-maskable signals:\n\nZOMBIE\nThis non-maskable signal is fired if a program has received an \"IDLE\" signal but neither\nrestarted nor exited. The program has become a zombie (that is, it's neither dead nor alive,\nand only exists to consume braaaains ...er... memory). The \"ZOMBIE\" signal acts like a\ncricket bat to the head, bringing the zombie down, for good.\n\nUIDESTROY\nThis non-maskable signal indicates that a program's user interface has been closed, and the\nprogram should take the user's hint and buzz off as well. It's usually generated when a\nparticular GUI widget is closed.\n\nCommon Signal Dispatching\nMost signals are not dispatched to a single session. POE's session lineage (parents and\nchildren) form a sort of family tree. When a signal is sent to a session, it first passes\nthrough any children (and grandchildren, and so on) that are also interested in the signal.\n\nIn the case of terminal signals, if any of the sessions a signal passes through calls\n\"sighandled\"(), then the signal is considered taken care of. However if none of them do, then\nthe entire session tree rooted at the destination session is terminated. For example, consider\nthis tree of sessions:\n\nPOE::Kernel\nSession 2\nSession 4\nSession 5\nSession 3\nSession 6\nSession 7\n\nPOE::Kernel is the parent of sessions 2 and 3. Session 2 is the parent of sessions 4 and 5. And\nsession 3 is the parent of 6 and 7.\n\nA signal sent to Session 2 may also be dispatched to session 4 and 5 because they are 2's\nchildren. Sessions 4 and 5 will only receive the signal if they have registered the appropriate\nwatcher. If the signal is terminal, and none of the signal watchers in sessions 2, 4 and 5\ncalled \"sighandled()\", all 3 sessions will be terminated.\n\nThe program's POE::Kernel instance is considered to be a session for the purpose of signal\ndispatch. So any signal sent to POE::Kernel will propagate through every interested session in\nthe entire program. This is in fact how OS signals are handled: A global signal handler is\nregistered to forward the signal to POE::Kernel.\n\nSignal Semantics\nAll signals come with the signal name in ARG0. The signal name is as it appears in %SIG, with\none exception: Child process signals are always \"CHLD\" even if the current operating system\nrecognizes them as \"CLD\".\n\nCertain signals have special semantics:\n\nSIGCHLD\nSIGCLD\nBoth \"SIGCHLD\" and \"SIGCLD\" indicate that a child process has exited or been terminated by some\nsignal. The actual signal name varies between operating systems, but POE uses \"CHLD\" regardless.\n\nInterest in \"SIGCHLD\" is registered using the \"sigchild\" method. The \"sig\"() method also works,\nbut it's not as nice.\n\nThe \"SIGCHLD\" event includes three parameters:\n\nARG0\n\"ARG0\" contains the string 'CHLD' (even if the OS calls it SIGCLD, SIGMONKEY, or something\nelse).\n\nARG1\n\"ARG1\" contains the process ID of the finished child process.\n\nARG2\nAnd \"ARG2\" holds the value of $? for the finished process.\n\nExample:\n\nsub sigCHLD {\nmy( $name, $PID, $exitval ) = @[ ARG0, ARG1, ARG2 ];\n# ...\n}\n\nSIGPIPE\nSIGPIPE is rarely used since POE provides events that do the same thing. Nevertheless SIGPIPE is\nsupported if you need it. Unlike most events, however, SIGPIPE is dispatched directly to the\nactive session when it's caught. Barring race conditions, the active session should be the one\nthat caused the OS to send the signal in the first place.\n\nThe SIGPIPE signal will still propagate to child sessions.\n\nARG0 is \"PIPE\". There is no other information associated with this signal.\n\nSIGWINCH\nWindow resizes can generate a large number of signals very quickly. This may not be a problem\nwhen using perl 5.8.0 or later, but earlier versions may not take kindly to such abuse. You have\nbeen warned.\n\nARG0 is \"WINCH\". There is no other information associated with this signal.\n\nException Handling\nPOE::Kernel provides only one form of exception handling: the \"DIE\" signal.\n\nWhen exception handling is enabled (the default), POE::Kernel wraps state invocation in\n\"eval{}\". If the event handler raises an exception, generally with \"die\", POE::Kernel will\ndispatch a \"DIE\" signal to the event's destination session.\n\n\"ARG0\" is the signal name, \"DIE\".\n\n\"ARG1\" is a hashref describing the exception:\n\nerrorstr\nThe text of the exception. In other words, $@.\n\ndestsession\nSession object of the state that the raised the exception. In other words, $[SESSION] in\nthe function that died.\n\nevent\nName of the event that died.\n\nsourcesession\nSession object that sent the original event. That is, $[SENDER] in the function that died.\n\nfromstate\nState from which the original event was sent. That is, $[CALLERSTATE] in the function that\ndied.\n\nfile\nName of the file the event was sent from. That is, $[CALLERFILE] in the function that\ndied.\n\nline\nLine number the event was sent from. That is, $[CALLERLINE] in the function that died.\n\n*Note that the preceding discussion assumes you are using POE::Session's call semantics.*\n\nNote that the \"DIE\" signal is sent to the session that raised the exception, not the session\nthat sent the event that caused the exception to be raised.\n\nsub start {\n$poekernel->sig( DIE => 'sigDIE' );\n$poekernel->yield( 'someevent' );\n}\n\nsub someevent {\ndie \"I didn't like that!\";\n}\n\nsub sigDIE {\nmy( $sig, $ex ) = @[ ARG0, ARG1 ];\n# $sig is 'DIE'\n# $ex is the exception hash\nwarn \"$$: error in $ex->{event}: $ex->{errorstr}\";\n$poekernel->sighandled();\n\n# Send the signal to session that sent the original event.\nif( $ex->{sourcesession} ne $[SESSION] ) {\n$poekernel->signal( $ex->{sourcesession}, 'DIE', $sig, $ex );\n}\n}\n\nPOE::Kernel's built-in exception handling can be disabled by setting the\n\"POE::Kernel::CATCHEXCEPTIONS\" constant to zero. As with other compile-time configuration\nconstants, it must be set before POE::Kernel is compiled:\n\nBEGIN {\npackage POE::Kernel;\nuse constant CATCHEXCEPTIONS => 0;\n}\nuse POE;\n\nor\n\nsub POE::Kernel::CATCHEXCEPTIONS () { 0 }\nuse POE;\n" }, { "name": "Signal Watcher Methods", "content": "And finally the methods themselves.\n\nsig SIGNALNAME [, EVENTNAME [, LIST] ]" }, { "name": "sig", "content": "optional LIST of parameters that will be passed to the signal's handler---after any data that\ncomes wit the signal.\n\nIf EVENTNAME is defined, the signal handler is registered. Otherwise it's unregistered.\n\nEach session can register only one handler per SIGNALNAME. Subsequent registrations will\nreplace previous ones. Multiple sessions may however watch the same signal.\n\nSIGNALNAMEs are generally the same as members of %SIG, with two exceptions. First, \"CLD\" is an\nalias for \"CHLD\" (although see \"sigchild\"). And second, it's possible to send and handle\nsignals created by the application and have no basis in the operating system.\n\nsub handlestart {\n$[KERNEL]->sig( INT => \"eventuishutdown\" );\n$[KERNEL]->sig( bat => \"holysearchlightbatman\" );\n$[KERNEL]->sig( signal => \"mainscreenturnon\" );\n}\n\nThe operating system may never be able to generate the last two signals, but a POE session can\nby using POE::Kernel's \"signal\"() method.\n\nLater on the session may decide not to handle the signals:\n\nsub handleuishutdown {\n$[KERNEL]->sig( \"INT\" );\n$[KERNEL]->sig( \"bat\" );\n$[KERNEL]->sig( \"signal\" );\n}\n\nMore than one session may register interest in the same signal, and a session may clear its own\nsignal watchers without affecting those in other sessions.\n" }, { "name": "sig", "content": "sigchild PROCESSID [, EVENTNAME [, LIST] ]" }, { "name": "sig_child", "content": "exited. An optional LIST of parameters will be passed to the signal handler after the waitpid()\ninformation.\n\nThe watcher can be cleared at any time by calling sigchild() with just the PROCESSID.\n\nA session may register as many sigchild() handlers as necessary, but a session may only have\none per PROCESSID.\n" }, { "name": "sig_child", "content": "has been delivered. There's no point in continuing to watch for a signal that will never come\nagain. Other signal handlers persist until they are cleared.\n" }, { "name": "sig_child", "content": "POE's signal watchers.\n\nPrograms that wish to reliably reap child processes should be sure to call sigchild() before\nreturning from the event handler that forked the process. Otherwise POE::Kernel may have an\nopportunity to call waitpid() before an appropriate event watcher has been registered.\n\nPrograms that reap processes with waitpid() must clear POE's watchers for the same process IDs,\notherwise POE will wait indefinitely for processes that never send signals.\n" }, { "name": "sig_child", "content": "sub forkedparent {\nmy( $heap, $pid, $details ) = @[ HEAP, ARG0, ARG1 ];\n$poekernel->sigchild( $pid, 'sigchild', $details );\n}\n\nsub sigchild {\nmy( $heap, $sig, $pid, $exitval, $details ) = @[ HEAP, ARG0..ARG3 ];\nmy $details = delete $heap->{ $pid };\nwarn \"$$: Child $pid exited\"\n# .... also, $details has been passed from forkedparent()\n# through sigchild()\n}\n\nsighandled" }, { "name": "sig_handled", "content": "currently active session. If the signal is terminal, the sighandled() call prevents POE::Kernel\nfrom stopping the sessions that received the signal.\n\nA single signal may be dispatched to several sessions. Only one needs to call sighandled() to\nprevent the entire group from being stopped. If none of them call it, however, then they are all\nstopped together.\n" }, { "name": "sig_handled", "content": "sub start {\n$[KERNEL]->sig( INT => 'sigINT' );\n}\n\nsub sigINT {\nwarn \"$$ SIGINT\";\n$[KERNEL]->sighandled();\n}\n\nsignal SESSION, SIGNALNAME [, ARGSLIST]" }, { "name": "signal", "content": "be passed to every interested handler. As mentioned elsewhere, the signal may be delivered to\nSESSION's children, grandchildren, and so on. And if SESSION is the POE::Kernel itself, then all\ninterested sessions will receive the signal.\n\nIt is possible to send a signal in POE that doesn't exist in the operating system. signal()\nplaces the signal directly into POE's event queue as if they came from the operating system, but\nthey are not limited to signals recognized by kill(). POE uses a few of these fictitious signals\nfor its own global notifications.\n\nFor example:\n\nsub someeventhandler {\n# Turn on all main screens.\n$[KERNEL]->signal( $[KERNEL], \"signal\" );\n}\n" }, { "name": "signal", "content": "nature of the failure:\n\nESRCH (\"No such process\")\nThe SESSION does not exist.\n\nBecause all sessions are a child of POE::Kernel, sending a signal to the kernel will propagate\nthe signal to all sessions. This is a cheap form of *multicast*.\n\n$[KERNEL]->signal( $[KERNEL], 'shutdown' );\n\nsignaluidestroy WIDGETOBJECT" }, { "name": "signal_ui_destroy", "content": "destruction of the program's user interface. When the WIDGETOBJECT destructs, POE::Kernel\nissues the non-maskable UIDESTROY signal, which quickly triggers mass destruction of all active\nsessions. POE::Kernel->run() returns shortly thereafter.\n\nsub setupui {\n$[HEAP]{mainwidget} = Gtk->new(\"toplevel\");\n# ... populate the main widget here ...\n$[KERNEL]->signaluidestroy( $[HEAP]{mainwidget} );\n}\n\nDetecting widget destruction is specific to each toolkit.\n" }, { "name": "Event Handler Management", "content": "Event handler management methods let sessions hot swap their event handlers at run time. For\nexample, the POE::Wheel objects use state() to dynamically mix their own event handlers into the\nsessions that create them.\n\nThese methods only affect the current session; it would be rude to change another session's\nhandlers.\n\nThere is only one method in this group. Since it may be called in several different ways, it may\nbe easier to understand if each is documented separately.\n\nstate EVENTNAME [, CODEREFERNCE]" }, { "name": "state", "content": "to by CODEREFERENCE will be called whenever EVENTNAME events are dispatched to the current\nsession. If CODEREFERENCE is omitted, the handler for EVENTNAME will be removed.\n\nA session may only have one handler for a given EVENTNAME. Subsequent attempts to set an\nEVENTNAME handler will replace earlier handlers with the same name.\n\n# Stop paying attention to input. Say goodbye, and\n# trigger a socket close when the message is sent.\nsub sendfinalresponse {\n$[HEAP]{wheel}->put(\"KTHXBYE\");\n$[KERNEL]->state( 'onclientinput' );\n$[KERNEL]->state( onflush => \\&closeconnection );\n}\n\nstate EVENTNAME [, OBJECTREFERENCE [, OBJECTMETHODNAME] ]\nSet or remove a handler for EVENTNAME in the current session. If an OBJECTREFERENCE is given,\nthat object will handle the event. An optional OBJECTMETHODNAME may be provided. If the method\nname is not given, POE will look for a method matching the EVENTNAME instead. If the\nOBJECTREFERENCE is omitted, the handler for EVENTNAME will be removed.\n\nA session may only have one handler for a given EVENTNAME. Subsequent attempts to set an\nEVENTNAME handler will replace earlier handlers with the same name.\n\n$[KERNEL]->state( 'someevent', $self );\n$[KERNEL]->state( 'otherevent', $self, 'othermethod' );\n\nstate EVENTNAME [, CLASSNAME [, CLASSMETHODNAME] ]\nThis form of state() call is virtually identical to that of the object form.\n\nSet or remove a handler for EVENTNAME in the current session. If an CLASSNAME is given, that\nclass will handle the event. An optional CLASSMETHODNAME may be provided. If the method name\nis not given, POE will look for a method matching the EVENTNAME instead. If the CLASSNAME is\nomitted, the handler for EVENTNAME will be removed.\n\nA session may only have one handler for a given EVENTNAME. Subsequent attempts to set an\nEVENTNAME handler will replace earlier handlers with the same name.\n\n$[KERNEL]->state( 'someevent', PACKAGE );\n$[KERNEL]->state( 'otherevent', PACKAGE, 'othermethod' );\n" }, { "name": "Public Reference Counters", "content": "The methods in this section manipulate reference counters on the current session or another\nsession.\n\nEach session has a namespace for user-manipulated reference counters. These namespaces are\nassociated with the target SESSIONID for the reference counter methods, not the caller. Nothing\ncurrently prevents one session from decrementing a reference counter that was incremented by\nanother, but this behavior is not guaranteed to remain. For now, it's up to the users of these\nmethods to choose obscure counter names to avoid conflicts.\n\nReference counting is a big part of POE's magic. Various objects (mainly event watchers and\ncomponents) hold references to the sessions that own them. \"Session Lifespans\" explains the\nconcept in more detail.\n\nThe ability to keep a session alive is sometimes useful in an application or library. For\nexample, a component may hold a public reference to another session while it processes a request\nfrom that session. In doing so, the component guarantees that the requester is still around when\na response is eventually ready. Keeping a reference to the session's object is not enough.\nPOE::Kernel has its own internal reference counting mechanism.\n\nrefcountincrement SESSIONID, COUNTERNAME" }, { "name": "refcount_increment", "content": "identified by a SESSIONID. To discourage the use of session references, the" }, { "name": "refcount_increment", "content": "The target session will not stop until the value of any and all of its COUNTERNAME reference\ncounters are zero. (Actually, it may stop in some cases, such as failing to handle a terminal\nsignal.)\n\nNegative reference counters are legal. They still must be incremented back to zero before a\nsession is eligible for stopping.\n\nsub handlerequest {\n# Among other things, hold a reference count on the sender.\n$[KERNEL]->refcountincrement( $[SENDER]->ID, \"pending request\");\n$[HEAP]{requesters}{$requestid} = $[SENDER]->ID;\n}\n\nFor this to work, the session needs a way to remember the $[SENDER]->ID for a given request.\nCustomarily the session generates a request ID and uses that to track the request until it is\nfulfilled.\n" }, { "name": "refcount_increment", "content": "failure, it returns undef and sets $! to be the reason for the error.\n\nESRCH: The SESSIONID does not refer to a currently active session.\n\nrefcountdecrement SESSIONID, COUNTERNAME" }, { "name": "refcount_decrement", "content": "identified by a SESSIONID. It is the counterpoint for refcountincrement(). Please see" }, { "name": "refcount_increment", "content": "sub finallysendresponse {\n# Among other things, release the reference count for the\n# requester.\nmy $requesterid = delete $[HEAP]{requesters}{$requestid};\n$[KERNEL]->refcountdecrement( $requesterid, \"pending request\");\n}\n\nThe requester's $[SENDER]->ID is remembered and removed from the heap (lest there be memory\nleaks). It's used to decrement the reference counter that was incremented at the start of the\nrequest.\n" }, { "name": "refcount_decrement", "content": "failure, it returns undef, and $! will be set to the reason for the failure:\n\nESRCH: The SESSIONID does not refer to a currently active session.\n\nIt is not possible to discover currently active public references. See POE::API::Peek.\n" }, { "name": "Kernel State Accessors", "content": "POE::Kernel provides a few accessors into its massive brain so that library developers may have\nconvenient access to necessary data without relying on their callers to provide it.\n\nThese accessors expose ways to break session encapsulation. Please use them sparingly and\ncarefully.\n\ngetactivesession" }, { "name": "get_active_session", "content": "reference to the program's POE::Kernel instance if no session is running at that moment. The\nvalue is equivalent to POE::Session's $[SESSION].\n\nThis method was added for libraries that need $[SESSION] but don't want to include it as a\nparameter in their APIs.\n\nsub somehousekeeping {\nmy( $self ) = @;\nmy $session = $poekernel->getactivesession;\n# do some housekeeping on $session\n}\n\ngetactiveevent" }, { "name": "get_active_event", "content": "string when called outside event dispatch. The value is equivalent to POE::Session's $[STATE].\n\nsub waypoint {\nmy( $message ) = @;\nmy $event = $poekernel->getactiveevent;\nprint STDERR \"$$:$event:$mesage\\n\";\n}\n\ngeteventcount" }, { "name": "get_event_count", "content": "POE::Loop class authors. It may be deprecated in the future.\n\ngetnexteventtime" }, { "name": "get_next_event_time", "content": "" }, { "name": "time", "content": "poekernelloop" }, { "name": "poe_kernel_loop", "content": "events.\n" }, { "name": "Session Helper Methods", "content": "The methods in this group expose features for POE::Session class authors.\n\nsessionalloc SESSIONOBJECT [, STARTARGS]" }, { "name": "session_alloc", "content": "SESSIONOBJECT. A list of optional STARTARGS will be passed to the session as part of the\n\"start\" event.\n\nThe SESSIONOBJECT is expected to follow a subset of POE::Session's interface.\n\nThere is no sessionfree(). POE::Kernel determines when the session should stop and performs the\nnecessary cleanup after dispatching stop to the session.\n" }, { "name": "Miscellaneous Methods", "content": "We don't know where to classify the methods in this section.\n\nnew\nIt is not necessary to call POE::Kernel's new() method. Doing so will return the program's\nsingleton POE::Kernel object, however.\n" } ] }, "PUBLIC EXPORTED VARIABLES": { "content": "POE::Kernel exports two variables for your coding enjoyment: $poekernel and $poemainwindow.\nPOE::Kernel is implicitly used by POE itself, so using POE gets you POE::Kernel (and its\nexports) for free.\n\nIn more detail:\n\n$poekernel\n$poekernel contains a reference to the process' POE::Kernel singleton instance. It's mainly\nused for accessing POE::Kernel methods from places where $[KERNEL] is not available. It's most\ncommonly used in helper libraries.\n\n$poemainwindow\n$poemainwindow is used by graphical toolkits that require at least one widget to be created\nbefore their event loops are usable. This is currently only Tk.\n\nPOE::Loop::Tk creates a main window to satisfy Tk's event loop. The window is given to the\napplication since POE has no other use for it.\n\n$poemainwindow is undefined in toolkits that don't require a widget to dispatch events.\n\nOn a related note, POE will shut down if the widget in $poemainwindow is destroyed. This can\nbe changed with POE::Kernel's \"signaluidestroy\" method.\n", "subsections": [] }, "DEBUGGING POE AND PROGRAMS USING IT": { "content": "POE includes quite a lot of debugging code, in the form of both fatal assertions and run-time\ntraces. They may be enabled at compile time, but there is no way to toggle them at run-time.\nThis was done to avoid run-time penalties in programs where debugging is not necessary. That is,\nin most production cases.\n\nTraces are verbose reminders of what's going on within POE. Each is prefixed with a\nfour-character field describing the POE subsystem that generated it.\n\nAssertions (asserts) are quiet but deadly, both in performance (they cause a significant\nrun-time performance hit) and because they cause fatal errors when triggered.\n\nThe assertions and traces are useful for developing programs with POE, but they were originally\nadded to debug POE itself.\n\nEach assertion and tracing group is enabled by setting a constant in the POE::Kernel namespace\nto a true value.\n\nBEGIN {\npackage POE::Kernel;\nuse constant ASSERTDEFAULT => 1;\n}\nuse POE;\n\nOr the old-fashioned (and more concise) \"constant subroutine\" method. This doesn't need the\n\"BEGIN{}\" block since subroutine definitions are done at compile time.\n\nsub POE::Kernel::ASSERTDEFAULT () { 1 }\nuse POE;\n\nThe switches must be defined as constants before POE::Kernel is first loaded. Otherwise Perl's\ncompiler will not see the constants when first compiling POE::Kernel, and the features will not\nbe properly enabled.\n\nAssertions and traces may also be enabled by setting shell environment variables. The\nenvironment variables are named after the POE::Kernel constants with a \"POE\" prefix.\n\nPOEASSERTDEFAULT=1 POETRACEDEFAULT=1 ./mypoeprogram\n\nIn alphabetical order:\n\nASSERTDATA\nASSERTDATA enables run-time data integrity checks within POE::Kernel and the classes that mix\ninto it. POE::Kernel tracks a lot of cross-referenced data, and this group of assertions ensures\nthat it's consistent.\n\nPrefix:
\n\nEnvironment variable: POEASSERTDATA\n\nASSERTDEFAULT\nASSERTDEFAULT specifies the default value for assertions that are not explicitly enabled or\ndisabled. This is a quick and reliable way to make sure all assertions are on.\n\nNo assertion uses ASSERTDEFAULT directly, and this assertion flag has no corresponding output\nprefix.\n\nTurn on all assertions except ASSERTEVENTS:\n\nsub POE::Kernel::ASSERTDEFAULT () { 1 }\nsub POE::Kernel::ASSERTEVENTS () { 0 }\nuse POE::Kernel;\n\nPrefix: (none)\n\nEnvironment variable: POEASSERTDEFAULT\n\nASSERTEVENTS\nASSERTEVENTS mainly checks for attempts to dispatch events to sessions that don't exist. This\nassertion can assist in the debugging of strange, silent cases where event handlers are not\ncalled.\n\nPrefix: \n\nEnvironment variable: POEASSERTEVENTS\n\nASSERTFILES\nASSERTFILES enables some run-time checks in POE's filehandle watchers and the code that manages\nthem.\n\nPrefix: \n\nEnvironment variable: POEASSERTFILES\n\nASSERTRETVALS\nASSERTRETVALS upgrades failure codes from POE::Kernel's methods from advisory return values to\nfatal errors. Most programmers don't check the values these methods return, so ASSERTRETVALS is\na quick way to validate one's assumption that all is correct.\n\nPrefix: \n\nEnvironment variable: POEASSERTRETVALS\n\nASSERTUSAGE\nASSERTUSAGE is the counterpoint to ASSERTRETVALS. It enables run-time checks that the\nparameters to POE::Kernel's methods are correct. It's a quick (but not foolproof) way to verify\na program's use of POE.\n\nPrefix: \n\nEnvironment variable: POEASSERTUSAGE\n\nTRACEDEFAULT\nTRACEDEFAULT specifies the default value for traces that are not explicitly enabled or\ndisabled. This is a quick and reliable way to ensure your program generates copious output on\nthe file named in TRACEFILENAME or STDERR by default.\n\nTo enable all traces except a few noisier ones:\n\nsub POE::Kernel::TRACEDEFAULT () { 1 }\nsub POE::Kernel::TRACEEVENTS () { 0 }\nuse POE::Kernel;\n\nPrefix: (none)\n\nEnvironment variable: POETRACEDEFAULT\n\nTRACEDESTROY\nTRACEDESTROY causes every POE::Session object to dump the contents of its $[HEAP] when Perl\ndestroys it. This trace was added to help developers find memory leaks in their programs.\n\nPrefix: A line that reads \"----- Session $self Leak Check -----\".\n\nEnvironment variable: POETRACEDESTROY\n\nTRACEEVENTS\nTRACEEVENTS enables messages pertaining to POE's event queue's activities: when events are\nenqueued, dispatched or discarded, and more. It's great for determining where events go and\nwhen. Understandably this is one of POE's more verbose traces.\n\nPrefix: \n\nEnvironment variable: POETRACEEVENTS\n\nTRACEFILENAME\nTRACEFILENAME specifies the name of a file where POE's tracing and assertion messages should\ngo. It's useful if you want the messages but have other plans for STDERR, which is where the\nmessages go by default.\n\nPOE's tests use this so the trace and assertion code can be instrumented during testing without\nspewing all over the terminal.\n\nPrefix: (none)\n\nEnvironment variable: POETRACEFILENAME\n\nTRACEFILES\nTRACEFILES enables or disables traces in POE's filehandle watchers and the POE::Loop class that\nimplements the lowest-level filehandle multiplexing. This may be useful when tracking down\nstrange behavior related to filehandles.\n\nPrefix: \n\nEnvironment variable: POETRACEFILES\n\nTRACEREFCNT\nTRACEREFCNT governs whether POE::Kernel will trace sessions' reference counts. As discussed in\n\"Session Lifespans\", POE does a lot of reference counting, and the current state of a session's\nreference counts determines whether the session lives or dies. It's common for developers to\nwonder why a session stops too early or remains active too long. TRACEREFCNT can help explain\nwhy.\n\nPrefix: \n\nEnvironment variable: POETRACEREFCNT\n\nTRACERETVALS\nTRACERETVALS can enable carping whenever a POE::Kernel method is about to fail. It's a\nnon-fatal but noisier form of ASSERTRETVALS.\n\nPrefix: \n\nEnvironment variable: POETRACERETVALS\n\nTRACESESSIONS\nTRACESESSIONS enables trace messages that pertain to session management. Notice will be given\nwhen sessions are created or destroyed, and when the parent or child status of a session\nchanges.\n\nPrefix: \n\nEnvironment variable: POETRACESESSIONS\n\nTRACESIGNALS\nTRACESIGNALS turns on (or off) traces in POE's signal handling subsystem. Signal dispatch is\none of POE's more complex parts, and the trace messages may help application developers\nunderstand signal propagation and timing.\n\nPrefix: \n\nEnvironment variable: POETRACESIGNALS\n\nUSESIGCHLD\nWhether to use $SIG{CHLD} or to poll at an interval.\n\nThis flag is enabled by default on Perl >= 5.8.1 as it has support for \"safe signals\". Please\nsee perlipc for the gory details.\n\nYou might want to disable this if you are running a version of Perl that is known to have bad\nsignal handling, or if anything hijacks $SIG{CHLD}. One module that is known to do this is\nApache.\n\nEnabling this flag will cause child reaping to happen almost immediately, as opposed to once per\n\"CHILDPOLLINGINTERVAL\".\n\nCHILDPOLLINGINTERVAL\nThe interval at which \"wait\" is called to determine if child processes need to be reaped and the\n\"CHLD\" signal emulated.\n\nDefaults to 1 second.\n\nUSESIGNALPIPE\nThe only safe way to handle signals is to implement a shared-nothing model. POE builds a *signal\npipe* that communicates between the signal handlers and the POE kernel loop in a safe and atomic\nmanner. The signal pipe is implemented with POE::Pipe::OneWay, using a \"pipe\" conduit on Unix.\nUnfortunately, the signal pipe is not compatible with Windows and is not used on that platform.\n\nIf you wish to revert to the previous unsafe signal behaviour, you must set \"USESIGNALPIPE\" to\n0, or the environment variable \"POEUSESIGNALPIPE\".\n\nCATCHEXCEPTIONS\nWhether or not POE should run event handler code in an eval { } and deliver the \"DIE\" signal on\nerrors.\n\nSee \"Exception Handling\".\n", "subsections": [] }, "ENVIRONMENT VARIABLES FOR TESTING": { "content": "POE's tests are lovely, dark and deep. These environment variables allow testers to take roads\nless traveled.\n\nPOEDANTIC\nWindows and Perls built for it tend to be poor at doing UNIXy things, although they do try. POE\nbeing very UNIXy itself must skip a lot of Windows tests. The POEDANTIC environment variable\nwill, when true, enable all these tests. It's intended to be used from time to time to see\nwhether Windows has improved in some area.\n", "subsections": [] }, "SEE ALSO": { "content": "The SEE ALSO section in POE contains a table of contents covering the entire POE distribution.\n", "subsections": [] }, "BUGS": { "content": "* There is no mechanism in place to prevent external reference count names from clashing.\n\n* There is no mechanism to catch exceptions generated in another session.\n\nAUTHORS & COPYRIGHTS\nPlease see POE for more information about authors and contributors.\n", "subsections": [] } } } }