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 (because I verified that the connection is established correctly, and fpRecv even returns the data read from the connection).

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 socketerror.
- Is socketerror thread-safe? My application is multi-threaded - maybe it reads the result of another thread's socket operation.

Greetings,
MegaBrutal

In our previous episode, MegaBrutal said:

No, it doesn't. It did before 2003, but then it was changed, so now fprecv return value signals success or not.

This is more like normal sockets conventions.

For a while, deprecated functions without fp did implement it, but they have been deprecated since (long) before 2.2.0 and have been removed along the way. (in 2.4.0 and 2.6.0)

- Is socketerror thread-safe? My application is multi-threaded - maybe it reads the result of another thread's socket operation.

Afaik it is. On Windows it is an alias for wsagetlasterror on *nix mostly for threadsafe errno.

Once upon a time, on 12/23/2012 02:36 PM to be precise, MegaBrutal said:

And what does fpRecv() return? Does it return something >= 0? In that case the error comes from somewhere else.

As to your question wether SocketError() is thread-safe. On *nix (tested on Mac OS X 10.6.8 and several Linuxes) it is, I'm using this function in a multithreaded server and it's results are consistent with what I expect on a per-thread basis.