[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vdhdg1$2qrst$2 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-10-01, Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>> In article <vdgp60$2nh73$1 at dont-email.me>,
>> Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>
>>>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?
>>
>
>They don't enqueue events to the GUI event queue itself (at least
>on the GUIs I am aware of). See my detailed response to John about
>Android and look at the link I posted earlier.
>
>Non-GUI threads on Android have no direct access to the GUI and they
>have to communicate with the GUI thread via some form of generic
>messaging and let code running within the GUI thread perform the GUI
>operations on their behalf.

Sure. But, at least as far as the point I was trying to make,
this is a distinction without a difference.  The point is that
the GUI exists in a shared address space with other threads, and
must be intelligent about doing so.  Even something as simple as
memory allocation must be thread-safe.

        - Dan C.