> This is not true!
Yes it is! And it really isn't that hard to find, especially when I keep
pointing it out.
It's also a pervasive problem affecting the entire library, with a core loss
of functionality.
> When you call 'bind' in server code, then it do just BIND and nothing
> else! There is not any placa for any canread or others what can
> replace error message.
As I told you in the message, I was using the httpserv code as a common,
easy-to-use base for us all to explore, diagnose, and hopefully FINALLY
remedy this situation. Bind() actually DOES recognize the error, but if
RaiseExcept is not set, won't do anything about it. The HTTP daemon code
(like all sorts of other code) then goes directly into Listen() where it
REDEFINES the previously properly set LastError (10048) to the wrong 10022
and (repeatedly) sets the FLastErrorDesc to that wrong message.
THAT code definitely does call CanRead(), and it DOES hide the previous
errors (almost any operation after the error will clobber the fLastError
value); the same sort of thing that was happening with previous problems.
(Additionally ANY SERVER that actually wants to SERVE will eventually need
to LISTEN...)
Instead of talking at cross-purposes, let's try to walk through an example
together. This will get a *little* complicated, but hopefully we'll
establish *today* whether there's a problem or not.
-----------
I'll try to create instructions generic enough for all interested parties to
try this out.
Chances are I'll miss some details (I'm in a rush); hopefully they're
obvious enough... Otherwise, post a message and I'll try to fill in the
blanks.
1. Open httpserv in Delphi; compile it; make a copy of the httpserv.exe in
another location, so that it can be run independently. This way recompiles
in Delphi won't be stopped by the active program running. (Delphi can't
create httpserv.exe while the very same httpserv.exe is running.
2. Let's create a breakpoint in the TTCPHttpDaemon.create method. Navigate
to that routine, and place a breakpoint on the "bind('0.0.0.0', '80');"
line. Also add a watch on Sock.LastError.
3. OK. Here we go. Run the separately copied httpserv and activate the
server (push the button) to get an active server on port 80. Then run the
copy within Delphi's IDE to the breakpoint (also pushing the button to get
there). Note (for other readers) that the TTCPBlockSocket created in the
HTTPDaemon.create code creates the socket *object* but does not *bind* yet.
That happens in the thread's Execute setup code (just before the listening
loop).
4. As we're paused on the bind('0... line, look at the Sock.LastError
value in your Watch window. It should still be 0. Now let's trace into
Bind(). FLastError gets reset... You can either Step Over (F8) or set a
breakpoint on the line in Bind(Ip, Port : string) that says
"SockCheck(synsock.Bind... " .
5. When you get to SynSock.Bind() step INTO it (F7), tracing through till
you end up in SockCheck where you'll find that the SockResult parameter
is -1. It then does a WSAGetlLastError AND GETS THE PROPER 10048 and Error
Description. Trace back out of the routine; now we're back in
TBlockSocket.Bind().
6. Step Over till you get to ExceptCheck which we'll go INTO. (Note while
we're here, that FLastErrorDesc is already correctly set, but it gets set
again.) Now if RaiseExcept is not set, which it shouldn't be since we left
the code alone, the PROPER error is going to be ignored and we'll pass on
out of the ExceptCheck() method, and go straight into Listen()! The first
thing in Listen() (SockCheck) blanks out the FLastErrorDesc that was just
properly set, and then resets FLastError to 10022
AND THEN IT CONTINUES... ETC. ETC. ETC.
I'M OUT OF TIME right now. I've got to go without checking what I've just
written (just like I was rushing last night). Hopefully it's close enough.
I'll be back in a few hours.
I believe that this is enough information to fully demonstrate the issue in
*this* case, and to show that it's a pervasive problem (with some other
aspects) that affects the *entire* library.
Lukas, I'm definitely not doing this for FUN! Please investigate what I've
shown here. I'll try to help again later.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
