| … | |
… | |
| 13 | |
13 | |
| 14 | It does so by using L<AnyEvent|AnyEvent> to wait for readable/writable |
14 | It does so by using L<AnyEvent|AnyEvent> to wait for readable/writable |
| 15 | data, allowing other coroutines to run while one coroutine waits for I/O. |
15 | data, allowing other coroutines to run while one coroutine waits for I/O. |
| 16 | |
16 | |
| 17 | Coro::Handle does NOT inherit from IO::Handle but uses tied objects. |
17 | Coro::Handle does NOT inherit from IO::Handle but uses tied objects. |
|
|
18 | |
|
|
19 | If at all possible, you should I<always> prefer method calls on the handle object over invoking |
|
|
20 | tied methods, i.e.: |
|
|
21 | |
|
|
22 | $fh->print ($str); # NOT print $fh $str; |
|
|
23 | my $line = $fh->readline; # NOT my $line = <$fh>; |
|
|
24 | |
|
|
25 | The reason is that perl recurses within the interpreter when invoking tie |
|
|
26 | magic, forcing the (temporary) allocation of a (big) stack. If you have |
|
|
27 | lots of socket connections and they happen to wait in e.g. <$fh>, then |
|
|
28 | they would all have a costly C coroutine associated with them. |
| 18 | |
29 | |
| 19 | =over 4 |
30 | =over 4 |
| 20 | |
31 | |
| 21 | =cut |
32 | =cut |
| 22 | |
33 | |
