Jalon, Arnon wrote:
>
> I'm afraid that I don't have too much time to put towards it,
Well, you're the interested party here, so if you don't do it, it's just
going to go on the Wishlist. There it will sit for a few months waiting
for someone else to come along and do something about it.
We're letting you use tens of thousands of lines of our code for free.
It's not too much to ask for a hundred or so lines in return, is it?
> 1) You seem to be- rightfully- concerned about someone using the
> Connection object from a different thread
The locking mechanism is a legacy thing from before the change of
maintainership. It was never properly documented, so it isn't clear
exactly what they had in mind when they created it. Perhaps it was for
thread-safety, but if so, I agree that it's quite insufficient for that
as it stands now.
When v2.0 is released, this will continue to be the case, except that
the locking mechanism has been modified to allow future flexibility. We
plan to use that flexibility in a 2.x release to add optional mutexes in
place of the current weak locks, which will address this sort of concern.
This is another area where Patches Are Thoughtfully Considered (TM). We
have no objection to putting better locks into v2.0, if someone wants to
provide the patch. We just don't want to spend our time -- which will
delay the v2.0 release -- for something which doesn't absolutely have to
go into v2.0. If you want to tackle it, see the Wishlist in Subversion.
(Not the one in the latest release tarball...it's out of date now.)
> 2) Need to make sure that the MYSQL_RES wrapped by the Result is freed
> before call to next_results.
If this is mandated by the C API, then the best preventative is a good
example showing the proper pattern. If you re-use the same Result
object for storing each set, your condition will be met.
