>>> [...per-process default socket options...]
>> I'm not so sure why having default "options" for a process is such a
>> bad thing.
> It means any library that craetes a socket, including third party
> libraries, needs to know about this feature and specifically code
> around it.

Hm.  I hadn't thought about that.

This is a reason to have process-wide defaults, but it's also a reason
to have named sets of defaults that do not apply to naïvely-created
sockets.

In particular, you want to avoid process-wide defaults when you just
want to affect your own sockets, not those created by library routines;
but you *do* want process-wide defaults if you want certain options to
apply to *all* networking your process does, including that done by
not-yours library routines.

Is having this flexibility actually worth the complexity it would add?
That's debatable.  Personally, I think it's not; I'd dump process-wide
defaults, myself.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B