Hi Martin
> > > Yes. This is a problem with all Microsoft products. Porting 0MQ to to
> > > Win32 took approximately 50x more time than porting to any other
> > > platform. IOCP seems to be no different in this aspect.
> >
> > Well, while I'm not a MS fanboy, I will give them the benefit that
> > IOCP "can" be more efficient and have lower latency than epoll or kevent
> > versions. On the other hand, is 5% reduced memory bandwidth and
> slightly
> > more linear scaling really worth all the extra work? I don't think so
> An interesting intermediate step from a performance point of view might be
> to use WSAEventSelect() instead. This gives very good performance, however
> it suffers from the limitation that a single thread can only wait for a
> maximum of 64 event objects using WSAWaitForMultipleEvents(). I've not
> thought about this in detail, but it could possibly be worked around by
> creating worker threads inside the zmq::poller_t object; ugly but usable
> and still possibly less work than a full-blown IPC implementation.
I've used this in my zeroconf code and it works fine though it has
the standard problem of other select/etc items in terms of ending up scaling
non-uniformly as you go further with it. The difference is that the
overhead goes up quite steeply as you add more workers to handle each group
of 63 sockets. (63 since you reserve one for an interrupt/control handle.)
Obviously this is fine for something slow and not latency critical such as
the zeroconf stuff, but for 0mq it really seems about on par with the select
solution.
> Note that it's not clear whether or not WSAWaitForMultipleEvents() can be
> used on anything else besides sockets; i.e. if you can create an event
> object for a Named Pipe. This would also need to be investigated for the
> IOCP model; if we could get Named Pipes to work it would eliminate the
> horrible socketpair emulation used internally by zmq::signaler_t which
> causes all sorts of problems on Win32 (see e.g. issue#84 on Github).
You can put a normal event handle (not just the WSAEvent) into the
array and it works fine, at least since XP as I remember it. Even if you
can't use a pipe directly in the same manner, it should be easy to do an
overlapped IO with a wake able callback which could set the event directly.
I'll have to look at this again since I've not messed with Window's pipes
much, they used to be horribly broken except on servers and I always avoided
them. But that was "way" back pre-XP and I should probably invest some time
looking at them again.
> Another alternative for implementing both the ipc:// transport on Win32
> and
> a better zmq::signaler_t might be to use LPC:
>
> http://www.zezula.net/en/prog/lpc.html
>
> To summarize; there are several options out there, all better than what we
> have now. Advice, experience from the Win32 trenches and above all actual
> code is appreciated :-)
I'd likely suggest not using the lpc stuff. Unfortunately as an
undocumented API, there are no guarantee's it won't change out from under us
and of course you likely need to install the DDK and deal with all the
driver header pain that implies. I'll look at it a bit more but I tend to
shy away from requiring the DDK.
> On another note, in a separate message in the static linking thread we
> talked about which versions of the Win32 platform to support. In my
> opinion
> we don't need to care about anything pre-XP for any of this stuff, or if
> someone really cares we can of course fall back to the existing select()
> implementation which will limp along ok ...
I'd suggest the select option for pre XP. NT4/95/98/Me etc are just
way out of date anymore. Even XP is getting pretty long in the tooth and
given it is not being maintained any longer, I suspect it will be going away
gradually as Win7 is actually a decent replacement, unlike Vista.
KB
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
