|
From: Raymond C. R. <ra...@ba...> - 2011-08-16 06:28:21
|
Hi Mark (and anyone else out there) :)!
I've been looking at the network code trying to solve the deadlock
issue that was pointed out, and I have it partially solved, with a good
idea about what else I'll need to do. The problem seems to be that the
BeOS/Haiku BLock & BAutolock don't quite work as advertised, or at least
that I didn't understand them properly. The way I understood them, a
thread controlling a given lock can enter code that requests that lock
to be in place as much and as often as necessary, but it doesn't seem to
be behaving that way. Or perhaps I'm still not grasping some of the nuances.
Nonetheless, I've commented out a few of the locks, and Mark's
experimental code, more often than not, seems to be flying along,
requesting retrieval of images on pages that have been successfully
parsed. There are still some deadlock situations arising, but I'll be
able to eliminate those with time.
On other news, in the TCP layer (in particular in the connection
class), I have increased the size of the buffer used to actually receive
data from the network (in a recv call if I remember correctly) from 10
KB to 1 MB. As a result, the estimated bytes per second calculation has
typically jumped into the hundreds of thousands of bytes rather than a
few tens of thousands. Related to that, I have moved code that actually
processes that data in the HTTP layer from the layer manager loop into
the data is waiting notification callback function.
I'm sure I probably introduced new bugs as a result of these
changes, but I'm not done yet. I just wanted to put the code into
someone else's hands to test.
Raymond
|