Peter Djalaliev wrote:

> I think I know what functions need to hold what locks, at least for the
> functions that I need to use right now.  Are there any examples of
> locks and functions, such that you cannot hold that lock when you call
> that function?  I think I stumbled upon an example and I meant to ask
> about it, but I can't seem to find it anymore.

If a function acquires a certian lock, you should not call it while
already holding that lock.  There is also the lock ordering issue.

The lock documentation, what little there is, is at

> I thought that TCP, being a byte-oriented protocol, just waited until
> it gets from the Application layer enough bytes for a TCP segment and
> then sent the whole segment.  I guess some TCP implementations send
> data immediately to decrease the end-to-end delay.

Generally, when you write data to a TCP socket, you want TCP to send it
ASAP.  And that's how TCP normally does it.  The exception comes when
you're doing lots of short writes in rapid succession.  In that case,
TCP waits just a little bit to see if it can coalesce your data into a
larger segment.  But AFAIK, TCP never waits for a full segment.
There is no fixed segment size. There is only a MAX segment size (MSS).
When sending data much larger than the MSS, it tends to be sent as a
series of MSS segments, followed by one shorter one.  But for interactive
traffic, including http requests, short segments are the norm.

Nelson B
mozilla-crypto mailing list

Reply via email to