| Revision: | 1.3 |
| Committed: | Mon Nov 6 19:41:42 2006 UTC (17 years, 11 months ago) by root |
| Branch: | MAIN |
| CVS Tags: | rel-2_5, rel-4_91, rel-4_22, rel-4_21, rel-4_0, rel-4_3, rel-3_41, rel-5_151, rel-4_13, rel-4_11, rel-5_1, rel-5_0, rel-6_0, rel-6_5, rel-4_748, rel-3_55, rel-4_8, rel-4_9, rel-3_51, rel-4_741, rel-4_743, rel-4_742, rel-6_10, rel-4_744, rel-4_747, rel-6_13, rel-4_01, rel-4_03, rel-4_02, rel-3_6, rel-3_62, rel-3_63, rel-3_61, rel-3_4, rel-6_09, rel-6_08, rel-6_07, rel-6_06, rel-6_05, rel-6_04, rel-6_03, rel-6_02, rel-6_01, rel-5_161, rel-3_1, rel-4_74, rel-4_71, rel-4_72, rel-4_73, rel-5_371, rel-5_372, rel-6_512, rel-6_513, rel-6_511, rel-6_514, rel-5_22, rel-5_23, rel-5_24, rel-5_25, rel-6_32, rel-6_33, rel-6_31, rel-6_36, rel-6_37, rel-5_162, rel-5_2, rel-6_38, rel-6_39, rel-4_802, rel-4_803, rel-3_5, rel-4_801, rel-3_3, rel-3_2, rel-4_804, rel-3_0, rel-5_37, rel-5_36, rel-4_479, rel-6_23, rel-3_01, rel-6_29, rel-6_28, rel-6_46, rel-4_50, rel-4_51, rel-6_45, rel-4_4, rel-3_11, rel-4_45, rel-6_51, rel-6_52, rel-6_53, rel-6_54, rel-6_55, rel-6_56, rel-6_57, rel-4_745, rel-4_901, rel-4_49, rel-4_48, rel-4_1, rel-4_2, rel-4_746, rel-5_11, rel-5_12, rel-5_15, rel-5_14, rel-5_17, rel-5_16, stack_sharing, rel-4_47, rel-4_46, rel-4_7, rel-3_501, rel-6_43, rel-6_42, rel-6_41, rel-6_47, rel-5_132, rel-5_131, rel-6_44, rel-6_49, rel-6_48, rel-4_911, rel-4_912, rel-4_31, rel-4_32, rel-4_33, rel-4_34, rel-4_35, rel-4_36, rel-4_37, HEAD |
| Changes since 1.2: | +1 -1 lines |
| Log Message: | *** empty log message *** |
| # | Content |
|---|---|
| 1 | From: Marc Lehmann |
| 2 | To: "Eric G. Bergeron" |
| 3 | Subject: Re: About the Coro module |
| 4 | |
| 5 | > I am starting to use your perl Coro module and I think that I noticed a |
| 6 | |
| 7 | Well, perl is not really coro-safe, or was it that coro is not perl-safe? |
| 8 | :) |
| 9 | |
| 10 | It should work, but some corner cases, especially at global destruction, |
| 11 | are not handled as nice as they could. |
| 12 | |
| 13 | > bug (I just don't know where the bug is.). This code below seems to run the |
| 14 | > function 1 time too many. |
| 15 | > |
| 16 | > use Coro; |
| 17 | > use strict; |
| 18 | > my $proc=new Coro sub |
| 19 | > { my $i=0; |
| 20 | > while (1) |
| 21 | > { print "$i "; $i++; |
| 22 | > cede; |
| 23 | > } |
| 24 | > }; |
| 25 | > $proc->ready(); |
| 26 | > cede; |
| 27 | > $proc->ready(); |
| 28 | > cede; |
| 29 | |
| 30 | no, that's correct. "cede" is like the posix "yield" function. It |
| 31 | doesn't take the process out of the ready queue, it just gives other |
| 32 | processes the opportunity to run. |
| 33 | |
| 34 | So a single ->ready suffices to make it run as often as it wants - until |
| 35 | the main program exits, that is. |
| 36 | |
| 37 | The second ->ready call is actually a bug (not fatal), as it puts the |
| 38 | process a second time into the run queue. This is not a problem for |
| 39 | Coro, but not expected by you :) |
| 40 | |
| 41 | If you want to switch to another coro _without_ being put into the ready |
| 42 | queue automatically, don't use "cede" but "schedule". Schedule just |
| 43 | switches to another process and leaves the current one alone, while cede |
| 44 | is just a temporary switch - it will return later. |
| 45 | |
| 46 | Think of coros as processes. The Coro::State and Coro::Cont modules |
| 47 | implement different ideas, so you could roll your own stuff if you really |
| 48 | wanted to. |
| 49 | |
| 50 | A simple (althogh difficult to read) example is in one of the many |
| 51 | semaphore modules (e.g. Coro::Signal). The wait method for example: |
| 52 | |
| 53 | sub wait { |
| 54 | if ($_[0][0]) { |
| 55 | $_[0][0] = 0; |
| 56 | } else { |
| 57 | push @{$_[0][1]}, $Coro::current; # <- here |
| 58 | Coro::schedule; # <- here |
| 59 | } |
| 60 | } |
| 61 | |
| 62 | It first remembers the "current" process (the calling coro) internally |
| 63 | and then calls schedule, which cuases the process to stop running |
| 64 | immediately. Unless somebody else wakes it up it'll never run again. |
| 65 | "send" does this: |
| 66 | |
| 67 | sub send { |
| 68 | if (@{$_[0][1]}) { |
| 69 | (shift @{$_[0][1]})->ready; # <- here |
| 70 | } else { |
| 71 | $_[0][0] = 1; |
| 72 | } |
| 73 | } |
| 74 | |
| 75 | It puts the waiting process into the ready queue again. |
| 76 | |
| 77 | "cede" is implemented like this (in C, but the basic idea is the same): |
| 78 | |
| 79 | sub cede { |
| 80 | $current->ready; |
| 81 | schedule; |
| 82 | } |
| 83 | |
| 84 | so it put's itself into the ready queue and calls the scheduler. |
| 85 | |
| 86 | -- |
| 87 | -----==- | |
| 88 | ----==-- _ | |
| 89 | ---==---(_)__ __ ____ __ Marc Lehmann +-- |
| 90 | --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de |e| |
| 91 | -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ |
| 92 | The choice of a GNU generation | |
| 93 | | |
| 94 |