Re: [repro-devel] repro patches
Hello Byron,
Tuesday, October 16, 2007, 4:47:44 PM, you wrote:
> There actually isn't a double-free in ProcessorChain, since we take
> ownership from the auto_ptr passed in addProcessor() (see line 46).
> I see what you're trying to avoid in the patches to Data, but
> operator== is pulling an interesting trick to ensure that both are
> the same length.
This trick is smart, but...
> Now, I should note that we are assuming that lhs doesn't contain any
> nulls. (Data is geared such that it _can_ contain nulls in the middle
> of the string, since it can hold raw data.) If there was a null in
> just the right place (ie, in the same position as the end of rhs),
> the memcmp _could_ continue into uninitialized memory. Is this
> something we're willing to put up with?
Yes. In this function we assume that Data contain null-terminated
string. But this class have name Data, not String.
> The DB_THREAD thread-safety fix to BerkeleyDb is a good catch, and I
> think I understand the essence of the other fixes (I assume if we
> don't specify any of DB_DBT_MALLOC, DB_DBT_REALLOC, or
> DB_DBT_USERMEM, it will use static memory to hold the data, which
> won't be threadsafe?).
Moreover, as long as i can understand, if you use DB_THREAD flag
when open database, you MUST specify DB_DBT_MALLOC, DB_DBT_REALLOC, or
DB_DBT_USERMEM when you use DB->get (BerkeleyDb::dbReadRecord). When
you use cursor (BerkeleyDb::dbNextKey), using of DB_DBT_MALLOC is
optional. Cursors in Berkley db are not thread-safe, and access to
cursors must be serialized by application, for example, by mutex.
> The fixes to HttpBase look pretty straightforward, although I know
> squat about the Windows socket API.
I was read about closesocket() in MSDN.
Quotation: "An application should always have a matching call to closesocket
for each successful call to socket to return any socket resources to
the system."
--
Best regards,
Ruslan mailto:prostoruslan@xxxxxxxxx