Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104910
MIME-Version: 1.0
References: <CAJW__o1hA1DOp4Lf0LA2To5L-8c66+woFgoXAwfLaxxOiEwOPg@mail.gmail.com>
 <33dee569-a06f-c5ab-d358-f7b8df3f8a76@lsces.co.uk> <CAJW__o15H86GCBMrQ7Q33cAm-1iDYL38VVcff3aQL8Eu3mnSoQ@mail.gmail.com>
 <1166897a-379d-4e6f-d132-744171ea19d5@lsces.co.uk>
In-Reply-To: <1166897a-379d-4e6f-d132-744171ea19d5@lsces.co.uk>
Date: Sun, 24 Mar 2019 02:22:32 +0200
Message-ID: <CAJW__o05DMVQDswRoq7YdCANEYoqDreNqsG9iXdoZHcJQKOwfg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Unbundle ext/interbase
From: kalle@php.net (Kalle Sommer Nielsen)

Hi Lester

Den l=C3=B8r. 23. mar. 2019 kl. 23.41 skrev Lester Caine <lester@lsces.co.u=
k>:
> Thread safety is one area where the way the extension was structured
> originally may now be wrong, but the main problem with multiple
> connections is confined completely to multiple connections to a single
> database. In particular the 'default link' is actually the default
> transaction handle and additional links are simply multiple transactions
> on the one connection which I think is where some of the confusion has
> come from :( A more established Firebird user would simply start a new
> transaction, while a newbie may try to start a new connection. And in
> the past the extension has hidden that and quietly picked up the
> existing one ...

The default link should not be related to thread safety, it should be
related to the design of how database extensions used to be working.
The design was as follows (using the old ext/mysql as an example
here).

mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added=
 here

This is the "default" link. This is some magical behavior which made
the API very easy to use, however it also created some hard to debug
situations with multiple connections. ext/interbase seems to still go
by this design which is most likely the reason to why some of the
weirdness of the extension behavior after the blind updates to
somewhat work on PHP7.

Regarding the connection and fork(), is this a problem in other
database extensions, if not, then it may be worth it for whoever ends
up picking up the extension to look at how others do this. The design
of this extension is fairly old and prone to unforeseen errors.

> "A small subset of field types are supported, anything else crashes"
> This is news to me ... is there any bug report to back it up? All the
> current data types provided by Firebird are working in the extension,
> but you may well be right that we may be better off cloning the existing
> code and building a Firebird only port going forward. The concern is the
> same one we had with windows in the past, where adding extra extensions
> does not always work reliably ... one has to provide a wrapped package
> with all the edge cases addressed. But all my use in production is using
> ADOdb to wrap the database SQL problems ...

I count 13 open bugs[1] in regards to ext/interbase thats been
reported, there are probably a ton more. Bug#74946 talks about a crash
with a type, leading me to believe that if one type can crash, then
more are very likely too.


[1] https://bugs.php.net/search.php?cmd=3Ddisplay&bug_type=3DAll&status=3DO=
pen&package_name%5B%5D=3DInterBase+related&by=3DAny&limit=3D30


regards,

Kalle Sommer Nielsen
kalle@php.net