On Mon, Apr 25, 2011 at 22:26, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Mon, 25 Apr 2011, Paul Albrecht wrote:
>
>> I need the option set when the socket is created so
>> CURLOPT_SOCKOPTFUNCTION (setsockopt) is too late. I'll try the
>> CURL_OPENSOCKETFUNCTION (socket) which should work, but why is the callback
>> necessary? Shouldn't this be the default? Why would I want the connect
>> socket propagated to a forked process?
>
> Can you enlighten us when exactly this would cause anyone problems?

I can, I can! Sir, sir!

Reading from or writing to a socket from both the parent and the child
is an inherently race-y operation, you never know what process will
receive what data. Or vice versa, in what order data will be sent out.

You're going to say "Well! Don't do that then!" and you'd be right.
But this is a kind of bug that easily slips through yet is very
pernicious. To name something: libcurl's connection cache. I've never
tried it but I'm pretty sure that forking while it's active is going
to produce some rather interesting and unexpected results.

It's a good UNIX tradition to always open sockets and files with
F_CLOEXEC - or it used to be, anyway. But tradition or not, it's still
a good idea. :-)
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-04-25