Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105002 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 7897 invoked from network); 29 Mar 2019 16:04:47 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.204) by pb1.pair.com with SMTP; 29 Mar 2019 16:04:47 -0000 Received: (qmail 30713 invoked by uid 89); 29 Mar 2019 12:58:55 -0000 Received: by simscan 1.3.1 ppid: 30707, pid: 30710, t: 0.0505s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 29 Mar 2019 12:58:55 -0000 To: PHP Internals References: <2f7acce4-69dd-d98b-6f86-1110e3589c4b@lsces.co.uk> <27d7e310-f50d-5dad-1af8-345f77dfd102@lsces.co.uk> <0c833502-1017-5432-f3d4-ac608d864a19@gmx.de> Message-ID: Date: Fri, 29 Mar 2019 12:58:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Firebird - Who are WE ... From: lester@lsces.co.uk (Lester Caine) On 29/03/2019 12:05, Joe Watkins wrote: > No, it's broken in both modes. > > In NTS mode, both the thread that handles events (which illegally calls > user code) and the main thread are executing concurrently, they may both > be calling functions that cause interaction with module globals, which > are obviously shared between threads in NTS mode. > > You cannot just start threads and execute user code from anywhere, it's > not safe in NTS mode and is a horrible violation of share nothing in ZTS > mode. It's much more likely to break ZTS mode than NTS, but illegal in both. The main problem here is that Firebird events are not something one is likely to use when running a web service? Which is why simply disabling the events functions would be my own fix in the absence of anybody coming forward to say they ARE using them. Asynchronous access to third party services is an area that does require a much more cooperative code base? Simply asking for a query to run, going off to do other activity, and returning when the result is available is the sort of activity we are talking about here? From the Firebird docs ... > The event notification is asynchronous and takes place at the end of the transaction in which the event was generated. A separate thread is created by TIBEvents to wait on the event notification. When the event occurs it calls the “OnEventAlert” event handler to report which event has been received. Note that the event handler is run in the context of the main thread and hence there is no need to worry about thread synchronisation. So ibase_wait_event is sitting listening on the same connection that set the event handler and shares that connection which is where the current method of working comes from. But I have no idea if this can be changed. It is the firebird client which is actually holding the connection on which ibase_wait_event is listening. Using it depends very much on how PHP handles asynchronous events while I simply want to know that the read or write I've just done was successful or not ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk