(solved) Send() gives ENOTCONN after Connect() & WaitSelect()... any suggestions?

I'm trying to make Connect() be non-blocking. It seems to work if I use WaitSelect() to wait for ONLY that socket, before calling Send().

But if I wait on several sockets, then Send() _almost_ always gives the ENOTCONN error, which seems to imply that Connect() wasn't ready after all.

It's quite possible there's some stupid bug in my code somewhere (damned it I can see it), but I wondered if anyone was aware of any subtle "gotchas" that I might have overlooked? For example, is it possible for WaitSelect() to indicate an event has arrived for a particular socket, without Connect() actually being ready yet?

edit: And even more annoyingly, if I make it print extra debug info, then suddenly it seems to work. Which seems to suggest some kind of timing issue, although I don't know what.

@ChrisH

Or possibly it has something to do with socket sharing, se the manual how to enable it.

@LiveForIt
Can you give a little more detail? What do you mean by "socket sharing"?

I tried googling it, but didn't find anything very helpful. There were some mentions of re-using *ports* & even *addresses* (which don't seem useful in this context), but not sharing of "sockets" that I could see.

BTW, I checked, and every waiting socket I have uses a different port (as expected).

@ChrisH
Are you opening the socket in one process and accessing in another?

Sockets are unique to the process they're opened in. It is however possible to make a socket global, with ReleaseSocket and ObtainSocket.

In Jamiga I solved it by starting a new process for each socket, and communicating with the process instead of the socket. If you want I can point you to that code.

@jaokim
No, this is one process handling everything.

EDIT: It's starting to look more like a stupid bug (which'll take a lot of work to identify).

If you after the WaitSelect for several sockets, perform another WaitSelect on the socket you want - does it return the same thing?

@ChrisH


Quote:

So how are you checking that the WaitSelect() returned because that particular socket was now ready?

You should be checking the fd_set with FD_ISSET(fd, &write_set).

But also you need to check for a break signal / error ( return of -1 ) particularly as

Quote:

which I guessing could sugest a false positive for any sockest set .

Make sure nfds is set correctly, else false positives may also result there too.

@ChrisH

Quote:

Post your code and we'll be able to help with that (maybe).

I've found the bug. As is often the case, something was going wrong where I didn't expect it (and so wasn't looking very hard). When trying to wait on multiple sockets, my code never actually called WaitSelect() (doh), and so of course Connect() had usually not finished by then (unless I printed lots of debug stuff). (The bug was in code I'd used for before, without noticing any problem, sigh.)

@jaokim, LiveForIt
Thanks for your suggestions, as they did actually help me indirectly (reassuring me I hadn't overlooked some sockets "gotcha" + jaokim's last suggestion got me thinking from a different angle that led me to trying something that revealed the bug clearer).

edit:
@broadblues
Sorry, didn't see your posts until after I wrote the above.