> [...], as local SOCK_DGRAM sockets will return ENOBUFS when kernel is > out of buffer memory. As I understand, there is no way to sleeep > instead.
I've never investigated it in detail, but my understanding is that that's the usual semantic for SOCK_DGRAM. > I thought this was specific to SOCK_DGRAM, since SOCK_DGRAM is not > supposed to be reliable. I therefore added support for > SOCK_SEQPACKET (SOCK_STREAM is not relevant, I need atomicity) in the > kernel, but I face the very same problem, except that SOCK_SEQPACKET > local sockets will return EMSGSIZE when kernel is out of buffer > memory. Does SOCK_SEQPACKET even work? socket(2) on a handy 4.0.1 machine says "presently implemented only for PF_NS"; someone must have added it to AF_LOCAL, either after 4.0.1 or without updating socket(2). Neat. My reading is that SOCK_SEQPACKET is supposed to sleep: "...sequenced, reliable, two-way connection-based data transmission path for datagrams...". > The questions: > - did I miss a way to sleep on write when kernel is out of buffer > memory? Not AFAIK, FWTMBW. > - if this is impossible, what about adding a socket option for that? Good idea, I'd say. (Not necessarily easy; I haven't looked at the code. But good.) > - would it make sense to have such an option be the default for > SOCK_STREAM and SOCK_SEQPACKET? I think it is, for SOCK_STREAM. I've certainly not run into a case where it errors rather than sleeping when sleeping could alleviate a resource shortage. For SOCK_SEQPACKET, yes, I think it should be the default. Might even make sense to implement it for AF_LOCAL SOCK_DGRAM. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B