Indeed, Lawson. You may have seen it, but I provided a little more detail about accelerating plugin communications using Shared Memory segments in my answer<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000633.html>to Tigro.
In practice it's not easy to come up with an SM-accelerated path mechanism that preserves the semantics of communications on the socket path transparently, so I expect that these two paths would be kept separate. It wouldn't be too hard to implement an SM-based path into the viewer in parallel with the socket-based channel. I expect that most of the design battles would be about what shared data model to use. A sequential mailbox carrying by-reference payloads? A DOM-like structure? Locking with strong conventions? Lock-free update techniques? Software transactional memory? Retro semaphores and condition variables? Single assignment and no mutable state? Unfortunately all of these mechanisms have disadvantages and dangers --- there is no silver bullet in this area. The only way to win the SM multiprogramming game is to not play it, which is where we came in: socket messaging with no shared state. It's unfortunate that, occasionally, we have to break this rule for performance reasons. Morgaine. ============================= On Mon, Mar 8, 2010 at 6:40 PM, Lawson English <lengli...@cox.net> wrote: > Morgaine wrote: > >> >> >> PS. With regards to "Networking code in every plugin just to connect to >> the client", networking is made available by the operating system to every >> process through system calls or system subroutines, ie. the thinnest >> interface possible. There is no bloat or overhead involved. Particular >> languages sometimes pretty up the system interface a little, but these >> bindings do not normally introduce any significant overhead. Throughput and >> latency of socket communications is not a significant issue either --- I've >> measured them in an environment which emulated this design pattern, and the >> level of performance might even suit some rendering tasks. >> >> > When extra speed is needed, the shared memory design of the media plugin > can be used to augment/replace socket connections. The only caveat there is > that each OS has a limit on how many shared buffers can be used per > process/machine. > > On Mac OS X, without some superuser tweaking and maybe a restart, it's 8 > per process and 32 per machine. Other *nix have more I think and I have no > idea what Windows allows. Regardless, its something that should be used > sparingly. > > > Lawson > > > > > >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
