Multiproc woes

Well, I think I’ve figured out the infuriating problems I’ve been butting my head against with multiprocessing.

Turns out I can send and update objects and get them back with the changes intact, and I can send and update lists with the same kind of success… but I can’t send and update a list of objects, update the objects, and expect to get them back with their state updated.

So it looks like my ideal scenario of having a simple execution stack containing (among other things) a map object that tracks its tiles as a list is not going to work. I do think I can still use the stack for menus; if I’m recalling correctly (it was late last night), I can modify an object and update it by copying, modifying and replacing it in its list (which is stupid, inefficient and maddening, but works).

I’d like to see if processing or parallelpython can handle this scenario… but I’ve already burned so much time figuring it out in multiprocessing that I’m not too thrilled with the idea of trying to abandon it.

Either way… I did manage to get the input process passing commands to the top element of the execution stack, it just didn’t work as expected because of multiprocessing’s apparently-undocumented restriction on how many nested levels of data (about… one) you can depend on sharing between processes.

Comment

Commenting is closed for this article.

Trials and Tribulations

You've made your way to a brief record of the odd and intriguing events which constitute the development of my pet project, The Great Two-Dimensional Online RPG.

Tags

android, architecture, c++, client, crafting, ec2, git, graphics, ipc, java, leveling, maps, menus, movement, multiprocessing, processing, pydoc, pygame, python, queue, rendering, scaling, server, skills, stack, synchronization, textpattern


RSS Feeds

Search This Site