Ouch.
Per Hedeland wrote:
> Fitzsimons <> wrote:
>>> Stephan Maka wrote:
>>>>> Hi
>>>>>>>>> I'm unsure about the use of gen_tcp:controlling_process when I simply
>>> use a passive socket. Active sockets are no option here, I have strong
>>> traffic shaping requirements.
>>>>>>>> Your code starts working when you change the recv length to 0 (e.g.
>> unspecified) and stop expecting only one list elemet e.g. B instead of
>> [B].
>>>> No it doesn't - but it starts working when self() is evaluated in the
> original process instead of in the spawned one, i.e.
>>My only defense is I said "start working", but I don't think I have a
leg to stand on. ;-(
> But the socket *is* in raw mode in the sense referred to here, i.e.
> {packet, raw}, since that is the ("obvious") default. Though of course
> he should be using length 0 in any case, since 1 will be very
> inefficient and any other value is unlikely to have the wanted behaviour
> in this case (I think the manual is crystal clear on *that* aspect at
> least, you just need to read it:-).
>>Yes you are right. Apologies to the doc authors. I see now that raw
specifies no particular buffering so length is important, the other
options provide auto de-packetisation (for want of a better term) as a
convenience so length is meaningless. Thanks Per.
Sorry for the noise Stephan (and list).
Back to the original question: where is Stephan's occasional ebadf on
gen_tcp:recv coming from? It is not reproducible it with this code
(patched or unpatched). Round 2?
Cheers,
Bruce