Fwd: [REX] Re: new bsd-viewer
0 views
Skip to first unread message
daniel miller
Dec 23, 2008, 8:08:09 PM12/23/08
to realxtend-a...@googlegroups.com
yet again, my posts are bounced at realxtend group. Oh well, maybe
that's fate telling us to take it to this new list.
n Mon, Dec 22, 2008 at 8:56 PM, Hurliman, John <john.h...@intel.com> wrote:
> Technically, libomv runs in many threads. When you instantiate a GridClient object it exists in the thread it was created in. If you call client.Network.Login(), that sequence runs in the same thread. However, the packet processing in libomv is entirely asynchronous, so every packet handled or event fired from the library happens in an IOCP thread. .NET uses a hybrid system for IOCP threads, so some of these will be actual system threads that were sitting in a threadpool, while some of them are actually microthreads (fibers). The main takeaway is that you can assume every function in libomv that starts with .Begin*() will do the heavy lifting in a callback or start a worker thread, and any callback or handled packet from libomv will be executing in a different context as well.
>
I don't know much about the .net model, including IOCP's. I guess my
10K meter perspective is, concurrency is hard, and we better get it
right. I think Ryan is thinking this way. I just need time to get up
to speed on whatever it is we're going to be using, and I wanted to
point out the fact that various libraries might or might not play well
with our core system. Many times I've seen a great architecture
brought to its knees because a critical 3rd party piece of code is
constructed in some diametrically opposite style. Or, in the less
drastic case, the debugging and profiling tools do not cross the
divide between system components.
In this case, it sounds like .NET has some reasonable solutions for
these problems, and I'm willing to bet you and the omv team utilized
them correctly. But how will this help us, if this isn't a .NET/mono
project? If we just blindly port omv to C++, won't we be pulling the
rug out from under it, in the sense that C++ doesn't have IOCP and
fibers? Or maybe it does, with library so-and-such. But will that
solution play nice with the Intel game engine stuff that Ryan is
looking at?
I'm not trying to be negative; I've just seen this movie before, and I
want to try to avoid some pitfalls. Also, I'm busy, lazy, in need of
income, and/or getting old; I don't have the time or energy to study
up on more than a couple possible directions.
-danx0r
> No single programming model is ideal for every language, every operating system, etc. This model has been shown to have good performance with .NET on Windows (especially look at the recent improvements in .NET 3.5 SP1 with high performance sockets), and Mono has been steadily improving IOCP performance. The tradeoff, as Dan mentioned, is a lot of overhead (both in potentially buggy code and lock contention) managing data shared between threads.
>
> John
>
> >
>
that's fate telling us to take it to this new list.
n Mon, Dec 22, 2008 at 8:56 PM, Hurliman, John <john.h...@intel.com> wrote:
> Technically, libomv runs in many threads. When you instantiate a GridClient object it exists in the thread it was created in. If you call client.Network.Login(), that sequence runs in the same thread. However, the packet processing in libomv is entirely asynchronous, so every packet handled or event fired from the library happens in an IOCP thread. .NET uses a hybrid system for IOCP threads, so some of these will be actual system threads that were sitting in a threadpool, while some of them are actually microthreads (fibers). The main takeaway is that you can assume every function in libomv that starts with .Begin*() will do the heavy lifting in a callback or start a worker thread, and any callback or handled packet from libomv will be executing in a different context as well.
>
I don't know much about the .net model, including IOCP's. I guess my
10K meter perspective is, concurrency is hard, and we better get it
right. I think Ryan is thinking this way. I just need time to get up
to speed on whatever it is we're going to be using, and I wanted to
point out the fact that various libraries might or might not play well
with our core system. Many times I've seen a great architecture
brought to its knees because a critical 3rd party piece of code is
constructed in some diametrically opposite style. Or, in the less
drastic case, the debugging and profiling tools do not cross the
divide between system components.
In this case, it sounds like .NET has some reasonable solutions for
these problems, and I'm willing to bet you and the omv team utilized
them correctly. But how will this help us, if this isn't a .NET/mono
project? If we just blindly port omv to C++, won't we be pulling the
rug out from under it, in the sense that C++ doesn't have IOCP and
fibers? Or maybe it does, with library so-and-such. But will that
solution play nice with the Intel game engine stuff that Ryan is
looking at?
I'm not trying to be negative; I've just seen this movie before, and I
want to try to avoid some pitfalls. Also, I'm busy, lazy, in need of
income, and/or getting old; I don't have the time or energy to study
up on more than a couple possible directions.
-danx0r
> No single programming model is ideal for every language, every operating system, etc. This model has been shown to have good performance with .NET on Windows (especially look at the recent improvements in .NET 3.5 SP1 with high performance sockets), and Mono has been steadily improving IOCP performance. The tradeoff, as Dan mentioned, is a lot of overhead (both in potentially buggy code and lock contention) managing data shared between threads.
>
> John
>
> >
>
Reply all
Reply to author
Forward
0 new messages