> It certainly should be Unicode-capable; I have been using _T(
) and _txxx() for some time now. It would certainly be
> interesting to see how it compares!
> And finally I get a chance to use some proper Unicode code {:v)
Hmmm, you know that a very important thing about Unicode-compatilbility (in
addtion to _T() and _txxx()) is not expecting a particular size of a
character, and instead using sizeof(TCHAR), I'm certain.
So, by all means try it.
> I'd be quite happy to detect OS and install a different binary.
So you shouldn't even need to mess with MSLU.
> Great idea! Since I've never ever profiled before, it just never
> occurred to me. Remind me how? {:v)
If you're using VC7 or VC7.1, there's a free profiler available called
DevPartner Profiler Community Edition (IIRC). If you're using VC6, then it
has its own built-in profiler; but I have never used it, so can't give you
much info (MSDN is your friend).
> It doesn't use an "IO completion port" (at least I don't think so; it
> DOES use overlapped comms though). The receive thread basically blocks
> in a
> ::WaitCommEvent() call until something happens, and then if EV_RXCHAR
> is the event, it goes and uses ::ReadFile() (and of course
> GetOverlappedResult() ) to get the data.
The overlapped I/O model is also a fast one (maybe the fastest except
IOCP's). But see below for why in your case, IOCP should not be much better
than overlapped I/O.
> At the moment the calling code (in most of the programs I'm
> responsible for) has to poll because it can't return to /its/ calling
> code until it either has an answer to the message it sent, or a
> timeout occurs. Since it is VB code doing the calling, I don't have
> the luxury of being able to sleep until an event is signalled from
> there. {:v(
I don't get something. What makes you poll? Can't you just issue an
overlapped I/O, and wait for its results, and return to the VB app only
after that?
But if you *have* to poll for the data anyway, then I'm afraid IOCP's will
not be much better than overlapped I/O, since it's the polling which should
be the biggest performance killer in this situation.
> In the future I plan to write another OCX will act as a layer on top
> of this one; it will understand Modbus, and thus /it/ will do the
> waiting until something happens and it can then check if it has a
> complete message (thus, being more efficient than polling
> continuously). Sadly as we all know they want the software NOW, so I
> haven't got the time to write that part yet! I only got the chance to
> write this one because it solved a VB problem (in VB comms, you have
> to pump Windows messages to enable incoming comms to be received - but
> this opens up the danger of the user clicking another button or a
> background timer kicking in during the wait for a response, which
> could try and send another message, and it just gets stupid from there
> - the OCX means I can poll without pumping messages).
>
> If someone can point me to some useful info on IOCPs, what they are
> exactly, why they're better than the
::WaitCommEvent() approach + overlapped, etc., I'd be grateful. > I don't
understand enough about it to use it effectively.
You need a little reading on IOCP's (I/O Completion Ports).
For a very good introduction to IOCP's, check the "Writing Scalable
Applications for Windows NT" article by John Vert in the MSDN. Also, check
out the "Writing Windows NT Server Applications in MFC Using I/O Completion
Ports" (Ruediger Asche) and "Win32 Multithreading Performance" (Ruediger
Asche) articles for more in-depth information.
-------------
Ehsan Akhgari
List Owner: [EMAIL PROTECTED]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
I cook every chance in my pot. And only when it has been quite cooked do I
welcome it as my food.
-Thus Spoke Zarathustra, F. W. Nietzsche
