| … | |
… | |
| 105 | main 2 |
105 | main 2 |
| 106 | async 2 |
106 | async 2 |
| 107 | |
107 | |
| 108 | This nicely illustrates the non-local jump ability: the main program |
108 | This nicely illustrates the non-local jump ability: the main program |
| 109 | prints the first line, and then yields the CPU to whatever other |
109 | prints the first line, and then yields the CPU to whatever other |
| 110 | threads there are. And there there is one other, which runs and prints |
110 | threads there are. And there is one other, which runs and prints |
| 111 | "async 1", and itself yields the CPU. Since the only other thread |
111 | "async 1", and itself yields the CPU. Since the only other thread |
| 112 | available is the main program, it continues running and so on. |
112 | available is the main program, it continues running and so on. |
| 113 | |
113 | |
| 114 | In more detail, C<async> creates a new thread. All new threads |
114 | In more detail, C<async> creates a new thread. All new threads |
| 115 | start in a suspended state. To make them run, they need to be put into |
115 | start in a suspended state. To make them run, they need to be put into |
| … | |
… | |
| 255 | |
255 | |
| 256 | This method C<down>s the semaphore and returns a so-called guard |
256 | This method C<down>s the semaphore and returns a so-called guard |
| 257 | object. Nothing happens as long as there are references to it, but when |
257 | object. Nothing happens as long as there are references to it, but when |
| 258 | all references are gone, for example, when C<costly_function> returns or |
258 | all references are gone, for example, when C<costly_function> returns or |
| 259 | throws an exception, it will automatically call C<up> on the semaphore, |
259 | throws an exception, it will automatically call C<up> on the semaphore, |
| 260 | no way to forget it. even when the thread gets C<cancel>ed by another |
260 | no way to forget it. Even when the thread gets C<cancel>ed by another |
| 261 | thread will the guard object ensure that the lock is freed. |
261 | thread will the guard object ensure that the lock is freed. |
| 262 | |
262 | |
| 263 | Apart from L<Coro::Semaphore> and L<Coro::Signal>, there is |
263 | Apart from L<Coro::Semaphore> and L<Coro::Signal>, there is |
| 264 | also a reader-writer lock (L<Coro::RWLock>) and a semaphore set |
264 | also a reader-writer lock (L<Coro::RWLock>) and a semaphore set |
| 265 | (L<Coro::SemaphoreSet>). |
265 | (L<Coro::SemaphoreSet>). |
| … | |
… | |
| 307 | |
307 | |
| 308 | Both C<get> and C<put> methods can block the current thread: C<get> |
308 | Both C<get> and C<put> methods can block the current thread: C<get> |
| 309 | first checks whether there I<is> some data available, and if not, it block |
309 | first checks whether there I<is> some data available, and if not, it block |
| 310 | the current thread until some data arrives. C<put> can also block, as |
310 | the current thread until some data arrives. C<put> can also block, as |
| 311 | each Channel has a "maximum buffering capacity", i.e. you cannot store |
311 | each Channel has a "maximum buffering capacity", i.e. you cannot store |
| 312 | more than a specific number of items, which cna be confgiured when the |
312 | more than a specific number of items, which can be configured when the |
| 313 | Channel gets created. |
313 | Channel gets created. |
| 314 | |
314 | |
| 315 | In the above example, C<put> never blocks, as the default capacity is |
315 | In the above example, C<put> never blocks, as the default capacity |
| 316 | of a Channel is very high. So the foor loop first puts data into the |
316 | of a Channel is very high. So the for loop first puts data into the |
| 317 | channel, then tries to C<get> the result. Since the async thread hasn't |
317 | channel, then tries to C<get> the result. Since the async thread hasn't |
| 318 | put anything in there yet (on the firts iteration it hasn't even run |
318 | put anything in there yet (on the firts iteration it hasn't even run |
| 319 | yet), the result Channel is still empty, so the main thread blocks. |
319 | yet), the result Channel is still empty, so the main thread blocks. |
| 320 | |
320 | |
| 321 | Since the only other runnable/ready thread at this point is the squaring |
321 | Since the only other runnable/ready thread at this point is the squaring |
| … | |
… | |
| 332 | the Coro module itself nor any of its submodules will ever give up the |
332 | the Coro module itself nor any of its submodules will ever give up the |
| 333 | CPU unless they have to, because they wait for some event to happen. |
333 | CPU unless they have to, because they wait for some event to happen. |
| 334 | |
334 | |
| 335 | Be careful, however: when multiple threads put numbers into C<$calculate> |
335 | Be careful, however: when multiple threads put numbers into C<$calculate> |
| 336 | and read from C<$result>, they won't know which result is theirs. The |
336 | and read from C<$result>, they won't know which result is theirs. The |
| 337 | solution for this is to ither use a semaphore, or send not just the |
337 | solution for this is to either use a semaphore, or send not just the |
| 338 | number, but also your own private result channel. |
338 | number, but also your own private result channel. |
| 339 | |
339 | |
| 340 | L<Coro::Channel> can buffer some amount of items. It is also very |
340 | L<Coro::Channel> can buffer some amount of items. It is also very |
| 341 | instructive to read its source code, as it is very simple and uses two |
341 | instructive to read its source code, as it is very simple and uses two |
| 342 | counting semaphores internally for synchronisation. |
342 | counting semaphores internally for synchronisation. |
| … | |
… | |
| 466 | |
466 | |
| 467 | =head1 The Real World - Event Loops |
467 | =head1 The Real World - Event Loops |
| 468 | |
468 | |
| 469 | Coro really wants to run in a program using some event loop. In fact, most |
469 | Coro really wants to run in a program using some event loop. In fact, most |
| 470 | real-world programs using Coro's threads are written in a combination of |
470 | real-world programs using Coro's threads are written in a combination of |
| 471 | event-based and thread-based techniques, as it is easy to gett he best of |
471 | event-based and thread-based techniques, as it is easy to get the best of |
| 472 | both worlds with Coro. |
472 | both worlds with Coro. |
| 473 | |
473 | |
| 474 | Coro integrates well into any event loop supported by L<AnyEvent>, simply |
474 | Coro integrates well into any event loop supported by L<AnyEvent>, simply |
| 475 | by C<use>ing L<Coro::AnyEvent>, but can take special advantage of the |
475 | by C<use>ing L<Coro::AnyEvent>, but can take special advantage of the |
| 476 | L<EV> and L<Event> modules. |
476 | L<EV> and L<Event> modules. |
