On 03/19/2013 12:51 PM, Murphy McCauley wrote: > On Mar 19, 2013, at 10:35 AM, Saul St. John wrote: > >> Regarding pt 1: does running POX under PyPy allow for the program to take >> simultaneous advantage of all the cores in a multiprocessor machine? IOW, >> does PyPy not suffer from the "single executing thread" limitation that >> CPython's GIL imposes? > > Unfortunately, no. PyPy still has a global lock. Removing the global lock > in a language designed with one in mind is pretty hard. BUT, you can pass > the lock between threads better than CPython 2 does. CPython 3 actually does > better.
Oh, that is a bummer. I thought I'd read somewhere that transactional memory was going to obsolete the the need for a global lock someday. > POX is actually built with the GIL limitation in mind. Really leveraging > multiple cores would require a more complex programming model. POX keeps the > simpler model because the limitation is inescapable anyway. Could you expand on that a bit? Here's the background: In my application, the first packet of every flow needs to go to the controller, any switch might see that packet, and there might be a ton of switches. The controller does a fair amount of work on the packets it sees, but that work will almost certainly not modify global state, and there's almost no synchronization required between the threads handling the switches. My understanding is that the GIL is a significant scalability limitation in this architecture, since it effectively serializes the processing of OF messages received from any switch, globally. I was thinking about whether I could use multiprocessing to launch a completely separate process for each switch, and use POX more like an API for OpenFlow, packet parsing, and sockets, than as a controller-proper. Would that violate POX's programming model?
