Once upon a time, on 12/23/2012 02:36 PM to be precise, MegaBrutal said:
> Hi all,
>
> For some reason, when I read socketerror after calling fpRecv just
> after I established a connection, I get 183, or (on a very rare
> occasion) 10061. I couldn't find what 183 is supposed to mean, but
> 10061 is
In our previous episode, MegaBrutal said:
>
> fpRecv works correctly if I read after I written something first.
>
> I suspect 2 possible causes:
> - Is socketerror reset to 0 after a successful socket operation? Actually,
> I call fpRecv and then try to verify if it was successful by examining
>
Hi all,
For some reason, when I read socketerror after calling fpRecv just after I
established a connection, I get 183, or (on a very rare occasion) 10061. I
couldn't find what 183 is supposed to mean, but 10061 is "connection
refused", which is strange because it's not applicable to the situation
[ Charset ISO-8859-1 unsupported, converting... ]
> > Ask your OS vendor. These are OS errors.
> > But:
> > 11 is iirc EAGAIN, which means "try again", which is due to a potential
> > deadlock in the kernel not being handled properly.
>
> You say that SocketErrors are OS errors but some influence
> Ask your OS vendor. These are OS errors.
> But:
> 11 is iirc EAGAIN, which means "try again", which is due to a potential
> deadlock in the kernel not being handled properly.
You say that SocketErrors are OS errors but some influence the FPC
compiler must have.
I modified my program a bit. It no
> I have a simple TCP program and I want to see when the client breaks the
> line.
> With the 205 compiler this is not a problem SocketError tells me, but with
> the 220 compiler nothing happens. Do I have to do something else?
>
> When compiled to 386 SocketError always returns 0, but when comp
I have a simple TCP program and I want to see when the client breaks the
line.
With the 205 compiler this is not a problem SocketError tells me, but with
the 220 compiler nothing happens. Do I have to do something else?
When compiled to 386 SocketError always returns 0, but when compiled to
ARM
