| Revision: | 1.3 |
| Committed: | Mon Nov 6 19:41:42 2006 UTC (19 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 *** |
| # | User | Rev | Content |
|---|---|---|---|
| 1 | pcg | 1.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 | root | 1.3 | It puts the waiting process into the ready queue again. |
| 76 | pcg | 1.1 | |
| 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 | root | 1.2 | --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de |e| |
| 91 | pcg | 1.1 | -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ |
| 92 | The choice of a GNU generation | | ||
| 93 | | | ||
| 94 |