Add a new background job and start it in a separate thread. There are two types of jobs which can be created: 1. Jobs based on expressions which can be passed to an eval() call. The expression must be given as a string. For example: job_manager.new('myfunc(x,y,z
(self, func_or_exp, *args, **kwargs)
| 104 | return self._completed |
| 105 | |
| 106 | def new(self, func_or_exp, *args, **kwargs): |
| 107 | """Add a new background job and start it in a separate thread. |
| 108 | |
| 109 | There are two types of jobs which can be created: |
| 110 | |
| 111 | 1. Jobs based on expressions which can be passed to an eval() call. |
| 112 | The expression must be given as a string. For example: |
| 113 | |
| 114 | job_manager.new('myfunc(x,y,z=1)'[,glob[,loc]]) |
| 115 | |
| 116 | The given expression is passed to eval(), along with the optional |
| 117 | global/local dicts provided. If no dicts are given, they are |
| 118 | extracted automatically from the caller's frame. |
| 119 | |
| 120 | A Python statement is NOT a valid eval() expression. Basically, you |
| 121 | can only use as an eval() argument something which can go on the right |
| 122 | of an '=' sign and be assigned to a variable. |
| 123 | |
| 124 | For example,"print 'hello'" is not valid, but '2+3' is. |
| 125 | |
| 126 | 2. Jobs given a function object, optionally passing additional |
| 127 | positional arguments: |
| 128 | |
| 129 | job_manager.new(myfunc, x, y) |
| 130 | |
| 131 | The function is called with the given arguments. |
| 132 | |
| 133 | If you need to pass keyword arguments to your function, you must |
| 134 | supply them as a dict named kw: |
| 135 | |
| 136 | job_manager.new(myfunc, x, y, kw=dict(z=1)) |
| 137 | |
| 138 | The reason for this asymmetry is that the new() method needs to |
| 139 | maintain access to its own keywords, and this prevents name collisions |
| 140 | between arguments to new() and arguments to your own functions. |
| 141 | |
| 142 | In both cases, the result is stored in the job.result field of the |
| 143 | background job object. |
| 144 | |
| 145 | You can set `daemon` attribute of the thread by giving the keyword |
| 146 | argument `daemon`. |
| 147 | |
| 148 | Notes and caveats: |
| 149 | |
| 150 | 1. All threads running share the same standard output. Thus, if your |
| 151 | background jobs generate output, it will come out on top of whatever |
| 152 | you are currently writing. For this reason, background jobs are best |
| 153 | used with silent functions which simply return their output. |
| 154 | |
| 155 | 2. Threads also all work within the same global namespace, and this |
| 156 | system does not lock interactive variables. So if you send job to the |
| 157 | background which operates on a mutable object for a long time, and |
| 158 | start modifying that same mutable object interactively (or in another |
| 159 | backgrounded job), all sorts of bizarre behaviour will occur. |
| 160 | |
| 161 | 3. If a background job is spending a lot of time inside a C extension |
| 162 | module which does not release the Python Global Interpreter Lock |
| 163 | (GIL), this will block the IPython prompt. This is simply because the |