php - How many instances of one class is there on server? -

is possible know how many instanced objects of 1 php class there on whole server (for users, not 1 thread).

here reason why want it. making card game , want have room class (with unique room name, players @ moment online in room, socked id ...) when user join server have fresh list of active rooms. , when 1 room canceled (destroyed) send users information (basically real-time room(s) status).

---

ok, here reason why want it. making card game project , want have room class (with unique room name, players @ moment online in room, socked id ...) when user join server have fresh list of active rooms. , when 1 room canceled(destroyed) send users information ( real-time room(s) status ). hope understand want do.

you want implement multi-user game, should use client-server architecture it: set single, persistent server process runs on machine , keeps track of game state. each user request handled php "client" script talks game server , asks necessary information.

that way, room objects , player state live in single process: server. webserver (not confused game server) launches client threads, , talk asynchronously game server in way want.

if situation simple, might able replace server process centralized database stores snapshot of current state of game (including full list of active rooms , associated players). each user request loads game state database, , writes out changes. think long-running server easier way go.

edit: question suggests confusion how php works. php threads launched server handle user requests short-lived. let's have 5 players who've been @ hour. every few minutes or seconds, player sends request webserver. server launches php thread handles request , exits. game might last hours, most of time there no running threads , no instances of class count. @ times, you'll have players without active connections. need some sort of persistent entity hold game state between requests, , might make unique.

edit 2: since seems you're little on head, maybe should go second option: forget inter-process communication , keep game state in database:

each php request 1 player action. when user clicks on button or whatever, php script loads database info needs model current state of game. necessary house-cleaning (deactivate users stopped playing long ago), handles user's action, saves changes database, , generates fresh page user. exits. takes small fraction of second. next user (or same user) submits action, , start again.

what concurrency? unless manage lot of users and scripts slow, there won't any: ever run 1 copy of script @ time. if want prohibit concurrent execution, use database transactions ensure user actions processed 1 @ time. if that's still not enough, learn client-server architectures, inter-process communication, , other stuff need client-server solution.