Winsock Vs. WaitForMultipleObjects()
David M Lowe
Hello;
I am porting a unix app to NT. We have a problem where
we want to block and wait for a select() IP port or for
a signaled handle.
Is there a way to code one of the following two cases;
1) Can I use a single object for the results of a
select inside of a waitForMutlipleObjects() call?
2) Can I create a munged SOCKET entry from a NT handle
that I can then pass to the select() function.
We are trying to implement an interprocess medium that
will appear as AF_UNIX to the application and don't want
to pay the price of opening a AF_INET socket to the
local machine. If we could hide a NT pipe behind the normal
AF_UNIX API (which we encapsulate) we expect a better
bandwith performance.
Miller
Charles Reitzel
You hit the weak spot in Winsock. WaitForMultipleObjects() cannot deal
with accept()'ing socket connections but select() cannot wait for
non-socket Win32 HANDLE's. So you need to use both in a creative way.
That might mean you have a thread with a blocking accept() call which
creates new sockets and passes them to the main thread which is in a
select() like WaitForMultipleObjects() loop. You *can* wait for socket I/O
in the WaitForXObjects() calls, although you can't port your unix code
directly to this framework because the error handling and closed connection
detection is different (and not as nice as select()). The important thing
is that you can share actual handling code for both Pipe and Socket
connections (or even serial port), as long as the data is the same.
Further, NT has got a unique but quite good asynchronous I/O arrangement
which allows you to scale the number of worker threads in the right way.
Look up I/O Completion Ports on your MSDN disc. Again, the handler code
can be independent of the type of connection by treating things like
generic HANDLE's. You do have to write connection specific code to create
and clean up the connections and associate handles with their sources. Not
pretty, but workable.
The other approach is to find a Unix compatiblity library, search for
NTOpen, a brand of Unix calls and shell commands for NT, including berkeley
sockets. Their select() may work the right way.
Charlie
crei...@tiac.net
David M Lowe <dl...@cnd.hp.com> wrote in article
<33722F...@cnd.hp.com>...
Gerbert Orasche
Hi!
On Thu, 08 May 1997 13:56:33 -0600, David M Lowe <dl...@cnd.hp.com>
wrote:
>I am porting a unix app to NT. We have a problem where
>we want to block and wait for a select() IP port or for
>a signaled handle.
>
>Is there a way to code one of the following two cases;
>
>1) Can I use a single object for the results of a
> select inside of a waitForMutlipleObjects() call?
>
>2) Can I create a munged SOCKET entry from a NT handle
> that I can then pass to the select() function.
>
>We are trying to implement an interprocess medium that
>will appear as AF_UNIX to the application and don't want
>to pay the price of opening a AF_INET socket to the
>local machine. If we could hide a NT pipe behind the normal
>AF_UNIX API (which we encapsulate) we expect a better
>bandwith performance.
I had the same problem. It is not possible to wait for a pipe handle
with select(). If you want to use named pipes instead of sockets:
I did some tests to compare the performance of these two and the
result was really surprising. When sending small packages (<150 bytes)
sockets are faster than named pipes! So it depends on the size of the
packets you are sending, if its worth to do the development afford...
cu
Gerbert Orasche
Hyperwave R&D, Schloegelgasse 9, A-8020 Graz, Austria
tel: ++43-316-820918-11
fax: ++43-316-820918-99
mailto://gora...@hyperwave.com
http://www.hyperwave.com
David M Lowe
Gerbert Orasche wrote:
> >We are trying to implement an interprocess medium that
> >will appear as AF_UNIX to the application and don't want
> >to pay the price of opening a AF_INET socket to the
> >local machine. If we could hide a NT pipe behind the normal
> >AF_UNIX API (which we encapsulate) we expect a better
> >bandwith performance.
>
> I had the same problem. It is not possible to wait for a pipe handle
> with select(). If you want to use named pipes instead of sockets:
I don't have this choice about using sockets as I have several
remote connections. What I must do is mix both signaled handles and
Winsock selects in the same paradigm. So far the popular answer has
been to create two threads one which waits on the select call, and
one that waits on the WaitForMultipleObjects call. As soon as either
unblocks it signals an event handle for the main thread to unblock
and come get the results.
I want to hide the handle information in a socket-looking array
mixed with winsock sockets and then put a pseudo-select() call on
top of the whole thing so we don't deviate from the unix code in the
select loop which drives the main program.
>
> I did some tests to compare the performance of these two and the
> result was really surprising. When sending small packages (<150 bytes)
> sockets are faster than named pipes! So it depends on the size of the
> packets you are sending, if its worth to do the development afford...
Did you try shared memory? Our current IPC abstraction understands
AF_INET and AF_UNIX, I would like to implement the NT AF_UNIX
implementation in shared memory, I'm not too concerned about the
setup time.
Miller
Ali Rezazadeh
Hello
I am looking for a spread sheet like OCX. We are using Visual C++ 4.2
and we want to have controls like a spreadsheet that would be editable
and users can modify the contents.
I appreciate any information.
Ali Rezazadeh
reza...@cadvision.com
Joe Willcoxson
Stingray (http://www.stingsoft.com) makes an excellent commercial grid.
You can find the freeware WorldCom MFC library which has a customizable
grid at http://users.aol.com/chinajoe/wcmfclib.html. VC++ 4.2 comes with
an OCX grid.
Ali Rezazadeh <reza...@cadvision.com> wrote in article
<338522...@cadvision.com>...
> I am looking for a spread sheet like OCX. We are using Visual C++ 4.2
> and we want to have controls like a spreadsheet that would be editable
> and users can modify the contents.
--
Joe Willcoxson (aka China Joe)
http://users.aol.com/chinajoe
#define STD_DISCLAIMER "I speak strictly for myself"
"Lotteries are taxes on people who don't understand statistics."