On Wed, Feb 5, 2014 at 11:55 AM, Olof Bjarnason <olof.bjarna...@gmail.com> wrote: > OK. The multiprocessing.Pool is a readable way of doing parallellization in > CPython. Basically run a method and collect results in a list (can it be > simpler than that?). It seems concurrent.futures has a similar syntax using > the ThreadPool. > > I had a vague hope threading module would have the same module available > (since their API is supposed to be 1:1), but cannot find it via from > threading import Pool (CPython 2.7.6).
Try from multiprocessing.pool import ThreadPool. IronPython should include the Python portions of multiprocessing (namely the 'dummy' module). If not, please open an issue and I'll include them in 2.7.5. > > For now I could just write a similar module in IPY myself, since I know .NET > Threads and the Pool api I need for my script. On more general note it's a > bit unfortunate that Pool isn't available in PyStdLib's threading module. > > Pool missing from threading might be more of a PyStdLib issue than > IronPython issue, but it affects me anyway. :) It's there, it's just in a weird spot and not documented. > >> >> > >> > I guess I could just switch to the threading module then. But does it >> > support Pool e.g., so I can re-use scripts I already have written? >> >> There is a thread pool in the multiprocessing library that I believe >> is pure Python and should work on IronPython (perhaps with some small >> patches). I haven't checked to see if concurrent.futures works; it'll >> have to for 3.0, but I'm not sure about the 2.7 backport. > > > Is it's in multprocessing, that isn't importable into IPY. But possibly I > can just copy-patch it to be able to use Pools + threading in IPY. Also an option, but I would like to make the multiprocessing ThreadPool usable in IronPython. > >> >> > >> > Is the semantics of thread the same as in Python, being "fake" >> > threading, >> > not separate processes, in the IPY version of threading? >> >> Each Python thread is 1:1 with a .NET thread, which I'm pretty sure >> are 1:1 with OS threads. Only one process is used (.NET, not >> surprisingly, takes a lot from Windows' computation model, where >> threads are cheap and processes are expensive). > > > Makes sense nomenclature wise, but not semantically for Python in general; > the question to ask is "would the Python scrip parallell_execution.py give > the same computation result running under both CPython and IronPython?" and > the answer would in general be "No" since Python Threads are running > sequentially/interleaved while the IronPython execution model relies on .NET > threads which is actually not interleaved (at least not in the Python GIL > sense .. it might be in the windows process-thread sense). This is getting > complicated :) Threading is always complicated. :) >> > Is there any CI mechanism for IronPython in place? TravisCI or similar? >> >> http://teamcity.codebetter.com/project.html?projectId=project110. Not >> in great shape right now, mainly because the IronPython tests are >> extremely difficult to run. Another thing on the 3.0 TODO list is >> getting that straightened out. > > > I get a login screen following that URL... Sorry, I forget to mention, just click "login as guest". - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
