| 160 | | # EventMachine::run initializes and runs an event loop. |
|---|
| 161 | | # This method only returns if user-callback code calls stop_event_loop. |
|---|
| 162 | | # Use the supplied block to define your clients and servers. |
|---|
| 163 | | # The block is called by EventMachine::run immediately after initializing |
|---|
| 164 | | # its internal event loop but <i>before</i> running the loop. |
|---|
| 165 | | # Therefore this block is the right place to call start_server if you |
|---|
| 166 | | # want to accept connections from remote clients. |
|---|
| 167 | | # |
|---|
| 168 | | # For programs that are structured as servers, it's usually appropriate |
|---|
| 169 | | # to start an event loop by calling EventMachine::run, and let it |
|---|
| 170 | | # run forever. It's also possible to use EventMachine::run to make a single |
|---|
| 171 | | # client-connection to a remote server, process the data flow from that |
|---|
| 172 | | # single connection, and then call stop_event_loop to force EventMachine::run |
|---|
| 173 | | # to return. Your program will then continue from the point immediately |
|---|
| 174 | | # following the call to EventMachine::run. |
|---|
| 175 | | # |
|---|
| 176 | | # You can of course do both client and servers simultaneously in the same program. |
|---|
| 177 | | # One of the strengths of the event-driven programming model is that the |
|---|
| 178 | | # handling of network events on many different connections will be interleaved, |
|---|
| 179 | | # and scheduled according to the actual events themselves. This maximizes |
|---|
| 180 | | # efficiency. |
|---|
| 181 | | # |
|---|
| 182 | | # === Server usage example |
|---|
| 183 | | # |
|---|
| 184 | | # See the text at the top of this file for an example of an echo server. |
|---|
| 185 | | # |
|---|
| 186 | | # === Client usage example |
|---|
| 187 | | # |
|---|
| 188 | | # See the description of stop_event_loop for an extremely simple client example. |
|---|
| 189 | | # |
|---|
| 190 | | #-- |
|---|
| 191 | | # Obsoleted the use_threads mechanism. |
|---|
| 192 | | # |
|---|
| 193 | | def EventMachine::run &block |
|---|
| 194 | | #def EventMachine::run use_threads = true, &block |
|---|
| 195 | | @conns = {} |
|---|
| 196 | | @acceptors = {} |
|---|
| 197 | | @timers = {} |
|---|
| 198 | | initialize_event_machine |
|---|
| 199 | | block and add_timer 0, block |
|---|
| 200 | | #use_threads ? run_machine : run_machine_without_threads |
|---|
| 201 | | run_machine |
|---|
| 202 | | release_machine |
|---|
| 203 | | end |
|---|
| | 160 | # EventMachine::run initializes and runs an event loop. |
|---|
| | 161 | # This method only returns if user-callback code calls stop_event_loop. |
|---|
| | 162 | # Use the supplied block to define your clients and servers. |
|---|
| | 163 | # The block is called by EventMachine::run immediately after initializing |
|---|
| | 164 | # its internal event loop but <i>before</i> running the loop. |
|---|
| | 165 | # Therefore this block is the right place to call start_server if you |
|---|
| | 166 | # want to accept connections from remote clients. |
|---|
| | 167 | # |
|---|
| | 168 | # For programs that are structured as servers, it's usually appropriate |
|---|
| | 169 | # to start an event loop by calling EventMachine::run, and let it |
|---|
| | 170 | # run forever. It's also possible to use EventMachine::run to make a single |
|---|
| | 171 | # client-connection to a remote server, process the data flow from that |
|---|
| | 172 | # single connection, and then call stop_event_loop to force EventMachine::run |
|---|
| | 173 | # to return. Your program will then continue from the point immediately |
|---|
| | 174 | # following the call to EventMachine::run. |
|---|
| | 175 | # |
|---|
| | 176 | # You can of course do both client and servers simultaneously in the same program. |
|---|
| | 177 | # One of the strengths of the event-driven programming model is that the |
|---|
| | 178 | # handling of network events on many different connections will be interleaved, |
|---|
| | 179 | # and scheduled according to the actual events themselves. This maximizes |
|---|
| | 180 | # efficiency. |
|---|
| | 181 | # |
|---|
| | 182 | # === Server usage example |
|---|
| | 183 | # |
|---|
| | 184 | # See the text at the top of this file for an example of an echo server. |
|---|
| | 185 | # |
|---|
| | 186 | # === Client usage example |
|---|
| | 187 | # |
|---|
| | 188 | # See the description of stop_event_loop for an extremely simple client example. |
|---|
| | 189 | # |
|---|
| | 190 | #-- |
|---|
| | 191 | # Obsoleted the use_threads mechanism. |
|---|
| | 192 | # 25Nov06: Added the begin/ensure block. We need to be sure that release_machine |
|---|
| | 193 | # gets called even if an exception gets thrown within any of the user code |
|---|
| | 194 | # that the event loop runs. The best way to see this is to run a unit |
|---|
| | 195 | # test with two functions, each of which calls EventMachine#run and each of |
|---|
| | 196 | # which throws something inside of #run. Without the ensure, the second test |
|---|
| | 197 | # will start without release_machine being called and will immediately throw |
|---|
| | 198 | # a C++ runtime error. |
|---|
| | 199 | # |
|---|
| | 200 | def EventMachine::run &block |
|---|
| | 201 | @conns = {} |
|---|
| | 202 | @acceptors = {} |
|---|
| | 203 | @timers = {} |
|---|
| | 204 | begin |
|---|
| | 205 | initialize_event_machine |
|---|
| | 206 | block and add_timer 0, block |
|---|
| | 207 | run_machine |
|---|
| | 208 | ensure |
|---|
| | 209 | release_machine |
|---|
| | 210 | end |
|---|
| | 211 | end |
|---|
| | 212 | |
|---|
