Very Computer

I just saw the following in a piece of code, and was wondering about how
portable this technique is:

s= socket()

if (!fork())
{
  connect(s,);
  exit(1);

Quote:}

FD_set(s, readset);

select(n, readset, ...);

Now, the reason for this is that  there may be several sockets being
handled, and so, rather than blocking waiting for the connect to finish,
fork it off.  The idea being that once the connect ifs finished, the other
end will send a byte, and the select will register it.

The problem is, it seems that on at least one system, the socket is coming
back as ready to read before the connect is finished (actually, since this
is happening when everything is on the same host, before the child even
gets ran).

I haven't had time to review Steven's yet (tonight when I get home), but I
th\ought I'd put out a feeler:

Is this a reliable technique or not?

Thanks,
mrc
--

    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Why don't you just make the socket non-blocking before calling connect?

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Quote:>Why don't you just make the socket non-blocking before calling connect?

Legacy.

I was helping someone with an open source project that he inherited from
someone else.  That someone else wrote the bit of code in question.

The current maintainer IS switching over to using non-blocking sockets; up
until this point it was a matter of "if it ain't broke, don't fix it."

However, it is surprising that this hasn't been a problem until now.

That's why I was curious about what the expected results should be.

mrc

--

    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc