… | |
… | |
29 | greatly reduced. |
29 | greatly reduced. |
30 | |
30 | |
31 | This module provides only low-level functionality. See L<Coro> and related |
31 | This module provides only low-level functionality. See L<Coro> and related |
32 | modules for a more useful process abstraction including scheduling. |
32 | modules for a more useful process abstraction including scheduling. |
33 | |
33 | |
|
|
34 | =head2 MEMORY CONSUMPTION |
|
|
35 | |
|
|
36 | A newly created coroutine that has not been used only allocates a |
|
|
37 | relatively small (a few hundred bytes) structure. Only on the first |
|
|
38 | C<transfer> will perl stacks (a few k) and optionally C stack (4-16k) be |
|
|
39 | allocated. On systems supporting mmap a 128k stack is allocated, on the |
|
|
40 | assumption that the OS has on-demand virtual memory. All this is very |
|
|
41 | system-dependent. On my i686-pc-linux-gnu system this amounts to about 10k |
|
|
42 | per coroutine. |
|
|
43 | |
34 | =over 4 |
44 | =over 4 |
35 | |
45 | |
36 | =cut |
46 | =cut |
37 | |
47 | |
38 | package Coro::State; |
48 | package Coro::State; |
… | |
… | |
44 | XSLoader::load Coro::State, $VERSION; |
54 | XSLoader::load Coro::State, $VERSION; |
45 | } |
55 | } |
46 | |
56 | |
47 | use base 'Exporter'; |
57 | use base 'Exporter'; |
48 | |
58 | |
49 | @EXPORT_OK = qw(SAVE_DEFAV SAVE_DEFSV SAVE_ERRSV); |
59 | @EXPORT_OK = qw(SAVE_DEFAV SAVE_DEFSV SAVE_ERRSV SAVE_CCTXT); |
50 | |
60 | |
51 | =item $coro = new [$coderef] [, @args...] |
61 | =item $coro = new [$coderef] [, @args...] |
52 | |
62 | |
53 | Create a new coroutine and return it. The first C<transfer> call to this |
63 | Create a new coroutine and return it. The first C<transfer> call to this |
54 | coroutine will start execution at the given coderef. If, the subroutine |
64 | coroutine will start execution at the given coderef. If, the subroutine |
55 | returns it will be executed again. |
65 | returns it will be executed again. |
56 | |
|
|
57 | The coderef you submit MUST NOT be a closure that refers to variables |
|
|
58 | in an outer scope. This does NOT work. |
|
|
59 | |
66 | |
60 | If the coderef is omitted this function will create a new "empty" |
67 | If the coderef is omitted this function will create a new "empty" |
61 | coroutine, i.e. a coroutine that cannot be transfered to but can be used |
68 | coroutine, i.e. a coroutine that cannot be transfered to but can be used |
62 | to save the current coroutine in. |
69 | to save the current coroutine in. |
63 | |
70 | |
… | |
… | |
90 | The "state" of a subroutine includes the scope, i.e. lexical variables and |
97 | The "state" of a subroutine includes the scope, i.e. lexical variables and |
91 | the current execution state. The C<$flags> value can be used to specify |
98 | the current execution state. The C<$flags> value can be used to specify |
92 | that additional state be saved (and later restored), by C<||>-ing the |
99 | that additional state be saved (and later restored), by C<||>-ing the |
93 | following constants together: |
100 | following constants together: |
94 | |
101 | |
95 | Constant Effect |
102 | Constant Effect |
96 | SAVE_DEFAV save/restore @_ |
103 | SAVE_DEFAV save/restore @_ |
97 | SAVE_DEFSV save/restore $_ |
104 | SAVE_DEFSV save/restore $_ |
98 | SAVE_ERRSV save/restore $@ |
105 | SAVE_ERRSV save/restore $@ |
|
|
106 | SAVE_CCTXT save/restore C-stack (you usually want this) |
99 | |
107 | |
100 | These constants are not exported by default. The default is subject to |
108 | These constants are not exported by default. The default is subject to |
101 | change (because we are still at an early development stage) but will |
109 | change (because we are still at an early development stage) but will |
102 | stabilize. |
110 | stabilize. |
103 | |
111 | |
… | |
… | |
105 | remember that every function call that might call C<transfer> (such |
113 | remember that every function call that might call C<transfer> (such |
106 | as C<Coro::Channel::put>) might clobber any global and/or special |
114 | as C<Coro::Channel::put>) might clobber any global and/or special |
107 | variables. Yes, this is by design ;) You can always create your own |
115 | variables. Yes, this is by design ;) You can always create your own |
108 | process abstraction model that saves these variables. |
116 | process abstraction model that saves these variables. |
109 | |
117 | |
110 | The easiest way to do this is to create your own scheduling primitive like this: |
118 | The easiest way to do this is to create your own scheduling primitive like |
|
|
119 | this: |
111 | |
120 | |
112 | sub schedule { |
121 | sub schedule { |
113 | local ($_, $@, ...); |
122 | local ($_, $@, ...); |
114 | $old->transfer($new); |
123 | $old->transfer($new); |
115 | } |
124 | } |