> > That conn->sem seems only to be waited for when running out > of memory. > > If you always send so little data that you never run out of > memory (or > > window size), it never gets waited for. Can any other developer say > > something on this? I think this behaviour is strange... > > I agree. It is treating it as a binary semaphore. >
Yes. And the reason that problem didn't occur to me is that my semaphores can count up to 0xFFFFFFFF since they don't have a maximum value. And reaching that level needs kind of long ;-) > It turns out sys_arch.txt says "Semaphores can be either > counting or binary > - lwIP works with both kinds." > > And my own port uses a counting semaphore. But the situation > that would tickle this problem would probably be infrequent > in practice, but certainly would appear to happen sometimes. > > I've had a quick look and I can't see any dependencies > elsewhere on it being a counting semaphore. So perhaps the > answer is that we must mandate a binary semaphore after all. I think a better solution would be to redesign tcp_sent() to signal the semaphore only if someone is really waiting. Otherwise some OSes could throw errors if a binary semaphore is signaled more than once. Simon _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
