Re: POE and the time
This discussion reminded me of: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time -- Jeremy Leader jlea...@oversee.net On 12/14/2012 09:52 PM, Chris Fedde wrote: A few comments about the wiki notes. First ntpd is careful about ensuring that time always moves forward. It does this by adjusting the clock slew rather than jumping time forwards or backwards. When ntpd first starts up and the system clock is not set within 5 seconds relative to its ntp servers then ntpd will die with a log message rather than jump the time. Within about an hour of starting ntpd can have the system synchronized within a few milliseconds of its best server. Some admins like to run ntpdate out of cron and force a time reset at regular intervals. It's never a good idea to force time jumps. It can case all kinds of trouble for databases, NFS, cryptography, process scheduler and even event systems written in perl. Most systems have a separate hardware clocks that is pretty accurate. OS time is typically synchronized with it at boot then runs independently of it. Some admins like to synch with hwclock out of cron. This is also a bad idea. On wintel type systems the hardware clock typically reports only down to seconds. This is much too rough for modern time keeping., Virtual machines add another whole layer of complexity to the picture. A vm will frequently have time jumps between time slices when it gets to run. Things that require real time behaviors probably should not be run in a vm. VM guests have to trust their host for an accurate representation of time. And all the issues that crop up above add another layer of complexity to accurate time keeping here There are very few good reasons for administrative clock adjustments. These days there are no good reasons based on simple calendrical causes. Soon even the dreaded leap second will be dealt with through math and lookup tables rather than clock adjustments. Nearly all other reasons to adjust the clock are political and organizational rather than technical. If we still want to deal with time sifts we have to detect them. When time jumps occur it is hard for a program to detect them. The only way that the program would know that time has changed is if it has two sources to compare. If such an event has been detected then it has to decide if there was a good administrative reason for the change or not. If the program decides to take action because it has detected a time change then it must have an array of logic to decide what special behaviors to apply for all of the various ways that the change could have occurred. Should it fire missed events? Should it recompute the offset for future events? what if the scale of the shift is large? What if the scale of the shift is tiny? What if time shifts occur frequently? What if they are noisy, crossing and recrossing the same point in time? We quickly get into pathological behaviors that either need to be accounted or ignored. Most developers who have cracked open this nut have eventually decided to leave well enough alone and have their system trust that the OS knows what time it is and that the admin had a good reason for mucking with the system time and leave it at that. Trying to correct for bad admin behavior is better done at the social layer than at the technical one. Just my thoughts. chris
Re: Pre-Announce : POE::Wheel::Sendfile
On 12/18/2010 09:47 AM, Philip Gwyn wrote: Greeting POElings, Following my work with Sys::Sendfile in the HTTP component, I decided that it would be useful enough on it's own. So I've concocted POE::Wheel::Sendfile. It is a straight sub-class of POE::Wheel::Sendfile that can use Sys::Sendfile to efficiently send a file over a network connection. I believe you meant it's a straight sub-class of POE::Wheel::ReadWrite I noticed the same typo in your POD description section. -- Jeremy Leader jlea...@oversee.net The initial draft is currently on the CPAN: http://search.cpan.org/perldoc?POE::Wheel::Sendfile TODO: - tests for the fall-back mechanism; - test with each loop, just in case; - POE::Wheel::Sendfile could be installed even though Sys::Sendfile isn't. I need a good way to signify this in Makefile.PL. -Philip
Re: How to deal with event timeout?
Can't you just use a name-based timer, re-set it every time you get any activity, and when it goes off (implying no activity for the duration of the timer), shut down? http://search.cpan.org/~rcaputo/POE-1.287/lib/POE/Kernel.pm#delay_set_EVENT_NAME,_DURATION_SECONDS_[,_PARAMETER_LIST] -- Jeremy Leader jlea...@oversee.net jlea...@alumni.caltech.edu Ryan Chan wrote: For example, I am using POE::Component::Client::NNTP http://search.cpan.org/~bingos/POE-Component-Client-NNTP-2.14/lib/POE/Component/Client/NNTP.pm This module does not specify any timeout, so sometimes my program seems hanged and does not response. Is it possible to specify a timeout or lifetime for the event, so it will quit when reached the specified time?
Re: run an interactive command using POE::Wheel?
Olivier Mengué wrote: 2009/9/24 Andreas Altergott alterg...@mira-consulting.net Please let me (us on the mailing list ;-) ) know if you do. It would be easier if the mailing list admin would reconfigure the list so we get poe@perl.org as the recipient when we choose Reply. More than once I made the mistake of replying only to the post author. Olivier. Actually, poe@perl.org *is* the To: address (the recipient) in the headers. I suspect you're really asking that poe@perl.org be made the sender (the From: header) or the Reply-To: header. I suggest you search your favorite search engine for reply-to munging considered harmful to read various explanations of why doing this makes the situation worse overall, not to mention violating RFC 2822. This seems to crop up every so often, and I've never understood why people are so reluctant to use their mail client's reply-all button/menu/command when they want to reply to all participants in a discussion. -- Jeremy Leader jlea...@oversee.net
