ugrás a tartalomhoz

az átkozott die. Avagy le tudom-e lőni a php scriptet igazából és miért hülyül meg leállásnál

Anonymous · 2006. Már. 22. (Sze), 21.01
most találkoztam a problémával. Eddig abban a hitben éltem, hogy a die abban különbözik az exit-től, hogy kilövi a php-t abban a pillanatban, amikor meghívom, és kész. Megkockáztatom, hogy php3 környékén így volt még, csak én nem frissítem a tudásomat a megszokott függvényeknél.
A PHP oldal szerint korrekten: alias ax exit()-re.

Szóval.
1. Ki tudom-e lőni a php-t úgy, hogy "Álljál le! most!"?. Na nem olyan megoldásokkal, hogy írok egy progit, ami megkeresi a pid-jét és nekivág egy SIGKILL-t, hanem úgy szépen, magából a kódból. Szerintem nem.

2. Miért hülyül meg?


Esettanulmány:

Intro:
Van egy User objektumom. Van egy NoSuchUser és egy SQLQuery Exceptionom. Van egy Errorhandlerem.

A User objektum vár egy userid-t konstruktorba, majd betölt, és a script futása alatt szépen tesz-vesz a memóriában, a destruktálásnál pedig mindent, amit tett-vett visszaírja az adatbázisba.


A Helyzet:
Létrehozok egy user objektumot egy nemlétező userid-vel. Erre eldob egy NoSuchUser Exceptiont. Ezt az errorhandler, mivel nem igazán tudja kijavítani leloggolja, majd azt mondja :die

De a die nem die, hanem becsülettel végighívogatja mindennek a destruktorát, igy a User-ét is. A user destruktora megpróbálja lementeni az adatbázisba a nemlétező User cuccait, hát de mivel nemlétező és ezértazért, dob egy SQLQuery Exceptiont. Beindul az autoloader, és keresi a file-t az SQLQueryException-nek.
De nem találja.

Ha die előtt jön megvan a file, ha die után jön, akkor bizony nincs meg egy file sem. Relatívhivatkozással, is_file(...)-lal.

Láttatok már ilyet??

tz
 
1

PEAR?

Hodicska Gergely · 2006. Már. 22. (Sze), 21.22
Nem PEAR-t használsz véletlenül? Mert az beregisztrál egy shutdown function-t, ami persze ilyenkor is lefut. Ha nem PEAR, akkor is szinte biztos, hogy ez van a háttérben. Szóval nem a die működik rosszul. Egy shutdown functionben kiadott exit hatására viszont ténylegesen megáll a működés.


Felhő
5

register_shutdown_function().

zottty · 2006. Már. 22. (Sze), 23.17
Nem PEAR, semmi spécizés.
A register_shutdown_function() még php4-ben volt egy amolyan workaroung a destruktotok helyett, bár gondolom a probléma teljesen analóg azzal, amit írsz. :)
2

Szemlélet...

janoszen · 2006. Már. 22. (Sze), 21.22
Hát figy. Ha objektorientáltan programozol, akkor csináld rendesen. OO programozó nem dobál taskkilleket. Egyébként meg exceptiont dobsz, kezeld le oszt kész. Ha fatal error kell, akkor oldd meg OO-san.
3

pont ezt csinálja

Hodicska Gergely · 2006. Már. 22. (Sze), 22.06
Nem tisztem megvédeni, de hát pont azt csinálja, amit itt írtál. :) A hibakezelőben mond csak exitet.


Felhő
4

Nem érted...

janoszen · 2006. Már. 22. (Sze), 23.08
Nem érted. OO programozásban nem szokás a program kellős közepén kilépni. A destruktornak meg pont az a szerepe, hogy ha fene fenét eszik, akkor is hajtódjon végre. Mert ugye, az a célja, hogy nyitva maradt erőforrásokat és hasonló dolgokat lezárjon. Annak meg végre kell hajtódnia akkor is, ha a futás kellős közepén elhasal a program, mert különben hogy nézünk ki.
6

nem érted

zottty · 2006. Már. 22. (Sze), 23.20
Ha nem fut le a konstruktor, miért fusson le a destruktor? Persze létrejön egy példány, csak nem az a példány, amit akarsz.

Aztán meg a webes OOP ott kezdődik, hogy csücsül mögötted egy alkalmazásszerver :)
8

elmélet vs gyakorlat

Hodicska Gergely · 2006. Már. 22. (Sze), 23.34
Szép dolog amit írtál, csak nem árt ismerni egy környezetet, amit használunk. PHP4-ben nincs hivatalosan destruktor. A PEAR a register_shutdown_function segítségével valósít meg hasonló funkcionalitást. (Ami mellesleg egy időben hibás volt, mert feleslegesen memóriában tartotta azokat az objektumokat is, amikre már nem volt szükség, nem tudom, hogy ezt azóta javították-e.)

Mert ugye, az a célja, hogy nyitva maradt erőforrásokat és hasonló dolgokat lezárjon.

Ami ugye PHP esetén automatikusan megtörténik a legtöbb esetben. Ezért hadd legyen a programozó felelőssége, hogy eldönthesse, hogy használ-e bármilyen olyan dolgot, ami kifejezetten szükségessé teszi a destruktor meghívását, főleg egy olyan használati esetben, amikor a program zátonyra futott.


Felhő
9

Megint nem érted.

janoszen · 2006. Már. 22. (Sze), 23.45
A filekezelés egy szép dolog, de nem csak erre értettem. Ha van mondjuk, egy adatbázis query-d, amelyik lockol egy táblát és mindennek tetejére félig beleír információt. És utána valamiért meghal a PHP alkalmazás. Akkor legjobb esetben is halál inkonzisztens lesz az adatbázisod, legrosszabb esetben (DB függő) lockolva marad a tábla és down lesz az egész szerver. Meggyőző?
10

adatbázis tervezés, tranzakció kezelés

Hodicska Gergely · 2006. Már. 23. (Cs), 00.04
Biztosan nem értem, viszont nem szoktam táblákat lockolni (valahogy mindig sikerült tervezéssel ezt elérni), és az általad említett félig beírás nem fordulhat elő, mert ilyen esetre tranzakciót illik használni, ami megvéd ez ellen. Szóval nem meggyőző.

Amúgy meg kifejezetten kiemeltem a fejlesztő felelősségét.


Felhő
12

lokkolás

zottty · 2006. Már. 23. (Cs), 00.24
Azt azért nem hiszem, hogy bármit sikerülne lockolás nélkül megoldanod. Én sokáig nem lockoltam, nagy terheltségű oldalakat, és kellett vagy 2 év, míg előjött egy hiba. de előjött.
Biztonságkritikus rendszereknél elkerülhetetlen.
Mondok egy példát

generálni akarsz egy nagy szórású egyedi id-t, megkockáztatom, ezt kb így csinálja mindenki:


--
id <- valamirandomrandom

amig létezik az adatbázisban ez az id:
... id <- valamirandomrandom

megvan, beleírom az adatbázisba
--


ebben az esetben simán előfordulha, hogy 2 script egyszerre fut le, és ugyanazt az id-t generálja, mert az első éppen a ciklusmagban van, mikor a
második éppen a ciklusfeltételnél.

Erre mondjál más megoldást lockolás nélkül, nem hiszem, hogy van, kiváncsi vagyok.
14

unique index vagy szekvencia

Hodicska Gergely · 2006. Már. 23. (Cs), 00.41
Simán megteheted azt is, hogy megpróbálod beszúrni (unique index a duplikáció kivédésére), ha hiba van, akkor ha a unique index miatt volt, akkor újra megpróbálod beszúrni egy újragenerált értékkel. Ha kellően nagy a szórása ennek a valaminek, akkor ez elég ritkán fog megtörténni.

Bár ha kifejezetten azonosítóra van szükség, akkor használhatsz szekvenciákat is. Vagy ha pl. egy index fa telítettségét szeretnéd ezzel a random cuccal segíteni, akkor pl. ezt a szekvenciát teheted a végére, vagy pl. megcserélsz benne egy részt, ezáltal nem lesz monoton növekvő.


Felhő
15

unique index

zottty · 2006. Már. 23. (Cs), 00.50
unique index a duplikáció kivédésére


Meggyőztél. :)
11

Miért ne értené?

LeslieNice · 2006. Már. 23. (Cs), 00.04
Itt most senki sem a destruktor fontosságát és létjogosultságát kritázálja!

Ha egy objektum példányosítás során a konstruktor nem fut le, mert az exception a konstruktorban keletkezik, akkor miért is hívódik meg a destruktora? Ez azért nem helyes. Ha nincsen példány akkor nincsen mire meghívni a destruktort, nem? Ezen esetben pedig az exception kezelés helyén a konstruktorban kell a kontruktorban megnyitott erőforrásokat bezárni és nem a destruktorban.

Egyébként miért kell mindenkit OOP nullának nézni ? :)

(Ja bocs hogy beleszóltam csak egy közös projektünkben jött elő a dolog)
13

ez az

zottty · 2006. Már. 23. (Cs), 00.27
A konstruktor ugye azért konstruktor, mert akkor épül fel a cucc.

Ha házat építek, és az első percben eltörik az ásó, akkor nem lesz ház. Hülyeség azt mondani, hogy na akkor ezt a házat most jól leromboljuk :)

A PHPben meg lesz ház. Ha elszáll a konstruktor, lesz objektum, csak nem lesznek kitöltve a változói :(
16

Jól van...

janoszen · 2006. Már. 23. (Cs), 10.45
Jól van, most ezen kár vitatkozni. Próbáltam elmagyarázni, mi foroghatott a PHP fejlesztők fejében... Így van és kész.

Ha lerakod az alap felét és utána törik el az ásó akkor vissza is kell szedni az alap felét, nincs mese.
17

inkább: ez van

Táskai Zsolt · 2006. Már. 23. (Cs), 10.53
azért az lásd, hogy igazi OO programozási nyelvekben (direkt heccelés, nem mellre szívni!) úgy van, ahogy fent írják: meg nem konstruált elemre nincs destruktor hívás. még jó. erre való az exception kezelő ága.
tényleg túlragoztuk a témát, viszont:
most akkor ezt így ki lehet jelenteni, hogy a destruktor PHP-ben "ha kell, ha nem" meghívódik? nagy tanulság...
Tasi
18

túlragozzuk

zottty · 2006. Már. 23. (Cs), 12.28
de miért szarik be a filekezelés a die után????
19

valami hasonló dolog

Hodicska Gergely · 2006. Már. 23. (Cs), 13.35
Áthoztam ide, hogy ne mérgesítsük Gobát.


Felhő
7

Nem akartam

zottty · 2006. Már. 22. (Sze), 23.26
Nem akartam módszertani vitát csinálni ebből. Akkor hirtelen mindannyian rettentő okosak és hülyeségeket beszélünk. Légyszi ne mondd meg, hogy hogy kell rendesen, ne húzzuk el a kérdést ebbe az irányba. :)

Akkor végül ilyen utasítás nincsen?
Bár a lényeg inkább az, hogy hogy megy ez? die közbeni függvényeknél meghal az filekezelés? Láttatok már ilyet?