Kevin's Weblog

The OSCON tutorials are 3 hours total, split in half with a 1/2 hour break. While the break is definitely good, 90 minutes is still too long to go continuously. I think it’s well known that it’s basically impossible for people to focus for more than 45-50 minutes or so. It might have been a better idea to do the tutorials in three 1-hour pieces, or maybe shorten them to two hours total.

Retrospective: This ended up being a little slow, and I suffered from trying to stay attentive the whole time. But, I think it was valuable and I’ll have a much better idea how to approach the docs when I get home and want to play around with this. I’m still not sure if it’ll be something I want to use, mostly because I don’t know what the performance characteristics of the system are.

POE is the core of a system originally designed for a multi-user game with a runtime that could be modified on-the-fly. At the core, basically an event loop that waits for events and calls handlers, which create more events, and so on. Events are queued when the system can’t handle everything in real-time.

Events, Sessions, Kernels

POE events are just lists of data from various sources.

• kernel
• event name
• sending session
• receiving session
• private data location for session
• for I/O events, socket or filehandle
• other application specific data

E.g., a session calls select_read for a socket and alarm_set, which creates events which are enqueued. When an event reaches the head, a callback is invoked (read from the socket, maybe) and this might post a new event (write to the socket). And around and around it goes.

Sessions are somewhat analogous to threads. They have a private data area which is reasonably encapsulated (but this is Perl, so if you really want to break the rules you can).

Sessions can be like “beans” or message-based interfaces. Events invoke a method on an object encapsulated by the Session. POE::Component::SubWrapper does all this for you.

You can use Session to modify event dispatch. Examples: NFA, MessageBased, MultiDispatch

Event fields are members of @_, not a hashref because that’s a lot slower. There are constants exported for field positions. Get your particular stuff with my @stuff = @_[ARG0..$#_]

Sessions only run as long as they have work to do. If they have no events or event watchers active, they get terminated. (Exception: a signal event watcher doesn’t keep a session alive by default.)

Use aliases to allow sessions to send events to other sessions. (Just friendly names, rather than unique numeric identifiers.)

Sessions can create child sessions. A child counts as work for the parent. POE::Kernel is the default child. Sessions get notification if their parent changes or if a child starts or terminates. This is not related to SIGCHLD.

Timer are events set to dispatch at a time in the future. Either absolute time or relative time

I/O watchers work like selects. Can start, stop, pause, and resume. They don’t actually perform I/O, they just watch for readiness. Your handler method should do all that.

Signal watchers look for OS signals or internal signals. Signals sent to a session are also sent to its children. If one session handles it, it’s handled for the whole tree. Makes it easier to do graceful shutdown and the like.

Wheels

Wheels are used to encapsulate common watcher patterns. They are not kept by the kernel, so your application needs to keep a reference. They create and destroy watchers and otherwise modify your session.

Filters translate data for a wheel - serialization and deserialization. Drivers perform file I/O, but basically POE::Driver::SysRW does everything you want.

Output is typically buffered in the driver.

POE::Wheel::Run runs programs and handles their I/O. Can modify permissions and priorities.

SocketFactory makes sockets with callback mechanism for success and failure via events.

Can set high- and low-water marks to detect slow connections and register events to deal with the situation. Also FlushEvent can be set to run when the buffer empies.

Miscellany

Can switch filters during a run. Useful for sending HTTP streams, or parsing headers line-by-line, then slurping up all the body.

Can switch events generated by a wheel. E.g., handle authentication, then pass off to main application.

With one and two halves tutorials under my belt, I’ve got mixed reviews. Damian’s talk was good, the afternoon ones not as good. I’m still trying to get into the mingling thing. There’s a few people I recognize from LA.pm and elsewhere who I haven’t had a chance to go say hi to. However, I did somehow end up having dinner with a big group of strangers last night.

Based on a shortage of sleep, and a review of the abstracts, I decided to skip out on morning sessions today. I was signed up for Patterns in Perl, but the handouts didn’t convince me I would get anything new out of it. I looked through the rest of the abstracts, but wasn’t real psyched about anything. So, I’m going to sit in the lobby and hack a bit and maybe even talk to some of the other people skipping.