| … | |
… | |
| 66 | |
66 | |
| 67 | =item Timing Deficiencies |
67 | =item Timing Deficiencies |
| 68 | |
68 | |
| 69 | POE manages to not have a function that returns the current time. This is |
69 | POE manages to not have a function that returns the current time. This is |
| 70 | extremely problematic, as POE can use different time functions, which can |
70 | extremely problematic, as POE can use different time functions, which can |
| 71 | differ by more than a second. In addition, most timer functions in POE |
71 | differ by more than a second - and user code is left guessing which one is |
| 72 | want an absoltue timestamp, which is hard to create if all you have is a |
72 | used. |
| 73 | relative time and no function to return the "current time". |
73 | |
|
|
74 | In addition, most timer functions in POE want an absoltue timestamp, which |
|
|
75 | is hard to create if all you have is a relative time and no function to |
|
|
76 | return the "current time". |
| 74 | |
77 | |
| 75 | AnyEvent works around this by using relative timer fucntions, in the hope |
78 | AnyEvent works around this by using relative timer fucntions, in the hope |
| 76 | that POE gets it right at least internally. |
79 | that POE gets it right at least internally. |
| 77 | |
80 | |
| 78 | =item Event Non-Ordering |
81 | =item Event Non-Ordering |
| … | |
… | |
| 85 | |
88 | |
| 86 | =item Child Watchers |
89 | =item Child Watchers |
| 87 | |
90 | |
| 88 | POE offers child watchers - which is a laudable thing, as few event loops |
91 | POE offers child watchers - which is a laudable thing, as few event loops |
| 89 | do. Unfortunately, they cannot even implement AnyEvent's simple child |
92 | do. Unfortunately, they cannot even implement AnyEvent's simple child |
| 90 | watchers: they are not generic enough. |
93 | watchers: they are not generic enough (even the POE implementation itself |
|
|
94 | isn't generic enough to let properly designed event loops such as EV use |
|
|
95 | their child watcher instead - it insist on doing it itself the slow way). |
| 91 | |
96 | |
| 92 | Of course, if POE reaps an unrelated child it will also output a message |
97 | Of course, if POE reaps an unrelated child it will also output a message |
|
|
98 | for it that you cannot suppress (which shouldn't be too surprising at this |
| 93 | for it. Very professional. |
99 | point). Very professional. |
| 94 | |
100 | |
| 95 | As a workaround, AnyEvent::Impl::POE will take advantage of undocumented |
101 | As a workaround, AnyEvent::Impl::POE will take advantage of undocumented |
| 96 | behaviour in POE::Kernel to catch the status fo all child processes. |
102 | behaviour in POE::Kernel to catch the status of all child processes. |
| 97 | |
103 | |
| 98 | Unfortunately, POE's child handling is racy: if the child exits before the |
104 | Unfortunately, POE's child handling is racy: if the child exits before the |
| 99 | handler is created (which is impossible to guarantee...), one has to wait |
105 | handler is created (which is impossible to guarantee...), one has to wait |
| 100 | for another event to occur, which can take an indefinite time (apparently |
106 | for another event to occur, which can take an indefinite time (apparently |
| 101 | POE does a busy-waiting loop every second, but this is not guarenteed |
107 | POE does a busy-waiting loop every second, but this is not guarenteed |
| … | |
… | |
| 129 | coredump. These are: HUP, INT, QUIT and TERM. |
135 | coredump. These are: HUP, INT, QUIT and TERM. |
| 130 | |
136 | |
| 131 | Although AnyEvent calls C<sig_handled>, removing it has no apparent |
137 | Although AnyEvent calls C<sig_handled>, removing it has no apparent |
| 132 | effects on POE handling SIGINT. |
138 | effects on POE handling SIGINT. |
| 133 | |
139 | |
|
|
140 | refcount_increment SESSION_ID, COUNTER_NAME |
|
|
141 | |
|
|
142 | Nowhere is explained which COUNTER_NAMEs are valid and which aren't - not |
|
|
143 | all scalars (or even strings) are valid counter names. Take your guess, |
|
|
144 | failure is of course completely silent. |
|
|
145 | |
|
|
146 | get_next_event_time() returns the time the next event is due, in a form |
|
|
147 | compatible with the UNIX time() function. |
|
|
148 | |
|
|
149 | And surely, one would hope that POE supports subsecond accuracy as |
|
|
150 | documented elsewhere, unlike the explanation above implies. Yet: |
|
|
151 | |
|
|
152 | POE::Kernel timers support subsecond accuracy, but don’t expect too |
|
|
153 | much here. Perl is not the right language for realtime programming. |
|
|
154 | |
|
|
155 | ... of course, Perl is not the right language to expect subsecond accuray |
|
|
156 | - the manpage author must hate Perl to spread so much FUD in so little |
|
|
157 | space. The Deliantra game server logs with 100µs-accuracy because Perl is |
|
|
158 | fast enough to require this, and is still able to deliver map updates with |
|
|
159 | little jitter at exactly the right time. It does not, however, use POE. |
|
|
160 | |
| 134 | Furthermore, since the Kernel keeps track of everything sessions do, it |
161 | Furthermore, since the Kernel keeps track of everything sessions do, it |
| 135 | knows when a session has run out of tasks to perform. |
162 | knows when a session has run out of tasks to perform. |
| 136 | |
163 | |
| 137 | This is impossible - how does the kernel now that a session is no longer |
164 | This is impossible - how does the kernel know that a session is no longer |
| 138 | watching for some (external) event (e.g. by some other session)? It |
165 | watching for some (external) event (e.g. by some other session)? It |
| 139 | cannot, and therefore this is wrong - but you would be hard pressed to |
166 | cannot, and therefore this is wrong - but you would be hard pressed to |
| 140 | find out how to work around this and tell the kernel manually about such |
167 | find out how to work around this and tell the kernel manually about such |
| 141 | events. |
168 | events. |
| 142 | |
169 | |
