php / php/php-src

Observer API: Correlated observer callbacks for a single invocation

Ouverte
#20,510 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Feature Status: Needs Triage
Langage dominant
C
Étoiles
40.4k
Forks
8.2k
Merge moyen
2 j 13 h
PR mergées (30 j)
96

Description

Description

Note:

I’ve already asked and explained part of this in another issue , but this is a broader feature request with example use cases.

Brief:

Observer API replacing zend_execute_ex hook provides notable benefits and one caveat (as it seems to me): there is no stable, per-invocation identifier that can be seen consistently across all observer callbacks.
Observer API callbacks are much like event handlers fired at the certain point of the lifecycle of an invocation, but they do not provide a means of identification of the invocation.
By being able to identify the invocation, information gathered in different events can be easily linked together for a meaningful “observation”.

Request:

  1. Adding a temporary to zend_execute_data (like op_array.reserved[] but per invocation) to be used for identification as developer sees fit
  2. Passing zend_execute_data (or the temporary at least) to other callbacks like zend_observer_error_cb

Use case examples:

  1. Associating runtime metrics like start time, end time, return value, exceptions together without having to retain them in memory until all infos are gathered.
  2. Associating infos gathered by means other than Observer API (e.g. hooking specific PDO functions, replacing other zif_handler handlers) with infos from callbacks.

It’s true that some of the infos named in 1st example can be easily linked together by a simple stack structure or HashTable (as pointed out in the above linked issue) but some others require more complex rules AFAICT and unnecessary bookkeeping.
zend_execute_data is already per-invocation, so I think it is cleaner and more straightforward to use that instead of each extension building and maintaining its own mapping.

P.S.: Please forgive me if there’s anything wrong with my thinking or writing; I’m not that experienced.


Cc: @bwoebi @ndossche

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par lire les points d’entrée de l’Observer API mentionnés dans l’issue : zend_execute_ex, zend_observer_error_cb et zend_execute_data, ainsi que l’utilisation de op_array.reserved[] et de zif_handler. Comparez avec la discussion associée dans l’issue 20336. Le travail est terminé lorsque la conception de la corrélation des invocations et les exigences relatives aux données du callback sont convenues et implémentées avec une couverture appropriée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
c, php
Domaine
backend-api-design, compilers
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.