On Fri, 1 Mar 2002, Craig Hughes wrote: > I don't understand the source of the problem. Is there a limit on the > "pipe size" that I wasn't aware of?
Yes, there's a kernel buffer size limit, typically around 8k these days but configurable. > In that case, you could solve the problem by introducing an intermediary > buffer using buffer(1) or mbuffer(1) or something. I don't really see > how spamc could avoid this without creating the buffer itself. It's > actually doing quite well by interleaving reads and writes. The fact > that the milter isn't reading until it's completely done writing doesn't > seem like spamc's fault. Unix processes that do two-way IPC within the same thread should always do one of two things: (1) Use a very strict ACKing protocol (like SMTP), so that neither peer produces output until it knows the other is prepared to accept input. (2) Use non-blocking writes, and always be prepared to consume input from their peer. A select() loop is the typical mechanism for determining when read is necessary and write is possible, but you still need non-blocking writes to avoid sending more than the pipe can buffer. That said, I don't know if spamc and spamd are single- or multi-threaded (haven't looked, though from your "interleaving reads and writes" comment I'd guess single); but milter is both multi-threaded *and* uses an SMTP- equivalent protocol to communicate with sendmail, so my guess is that the deadlock is between spamc and spamd, and has nothing directly to do with milter. _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
