Mailinglisten-Archive |
> > Da jeder Prozeß auf dasselbe Segment zugreift, müssen im Segment mehrere > > Flags untergebracht werden - deswegen bietet sich die Speicherung über ein > > Array an. > > Stop. Es geht doch nur darum zu triggern, ob neue Nachrichten vorliegen > oder nicht. Ach so, aber natürlich für jeden Client. Also pro Client ein > Array-Feld. Dann muß ich aber bei der Erstellung des > Shared-Memory-Bereichs ein Maximum an Clients festlegen, oder? Sonst > gibt's doch irgendwann einen Speicherüberlauf, wenn immmer mehr Clients > dazukommen. ?) Man braucht für das gesamte System nur ein Array, phpChat benutzt ein assoziatives Array, welches die Flags nach Session-IDs geordnet enthält: $flag_array[$session_id_client_1] = $message_status_client_1; $flag_array[$session_id_client_1] = $message_status_client_2; usw. Das sieht als Pseudocode für jeden Client dann so aus: ---- $flag_array = retrieve_flag_array_from_shared_memory(); // (macht alles mit Semaphoren etc.) $message_status = $flag_array[$my_session_id]; if($message_status) retrieve_new_message_from_database(); else idle(); ---- Natürlich ist die größe des Shared Memory Segments begrenzt, man kann sie ja bei der Erstellung angeben. Ich habe nicht genug in den PHP-Interna rumgewühlt, um herauszufinden, wie PHP die Variable tatsächlich im Speicher ablegt, aber ich nehme an, daß PHP eine serialisierte Version dort hineinschreibt. Damit wäre der Speicherverbrauch ca.: speicher = nr_clients * (session_id_laenge + flag_laenge + overhead) session_id_laenge ist 32 bei normalen Session-IDs flag_laenge ist bei booleschen Flags 1 (können ja nur 0 oder 1 sein) overhead ist beim Serialisieren je nach Datentyp unterschiedlich, hier kann man einfach mal auf der sicheren Seite bleiben und 16 Zeichen veranschlagen. Macht also 49 Zeichen pro Client, ergibt bei einer Segmentgröße von 64k 1337 mögliche Clients (dürfte ausreichen). 64k sind recht wenig, selbst wenn man die RAM-Größe in heutigen Desktop-PCs betrachtet. Till
php::bar PHP Wiki - Listenarchive