Revision: | 1.3 |
Committed: | Mon Nov 6 19:41:42 2006 UTC (17 years, 8 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 |