[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vdgp60$2nh73$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-09-30, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 9/30/2024 9:36 PM, Lawrence D'Oliveiro wrote:
>>> On Mon, 30 Sep 2024 20:48:53 -0400, Arne Vajhøj wrote:
>>>> The world is moving from forking processes to starting threads.
>>> 
>>> That was tried in the 1990s -- threads for everything, even multithreaded
>>> GUIs. It was soon discovered that was not a great idea.
>>
>> Practically all GUI's are multi-threaded.
>
>No. The GUIs I know of (GTK, Android, etc) are all single threaded and any
>other threads which need to use the GUI need to queue a request on the GUI
>thread.
>
>For example, in Android, you can define a Handler on the GUI thread which
>receives messages from other threads:
>
>https://developer.android.com/reference/android/os/Handler
>
>I tend to use:
>
>https://developer.android.com/reference/android/os/Handler#sendMessage(android.os.Message)
>
>to send messages from the other threads to the GUI thread.
>
>> At least a main thread and an event thread.
>>
>
>No. In the GUIs I am aware of, the main GUI thread _is_ the event thread.

Most modern applications, even graphical applications running on
hosted systems, are multithreaded.  Whether the programming
model of the GUI library is multithreaded or not is another
matter, but those things must be _capable_ of being used in a
multithreaded environment, which means that they need to at
least be able to participate in a locking protocol of some sort,
etc.  For example, the incoming event queue must have some sort
of interlocking on it in order to be accessible from multiple
threads, otherwise, how could other threads safely enqueue
events to it?

	- Dan C.