[opensource-dev] Client Plugin System Design

[Morgaine]

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 <lenglish5 at 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
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100308/674a2c44/attachment-0001.htm