Keresés

Új hozzászólás Aktív témák

  • Lortech

    addikt

    válasz FehérHolló #1774 üzenetére

    Debugolásról meg annyit, hogy tegyük fel, hogy normál módon akarod leállítani a szálakat, szerinted mindent megtettél ennek érdekében. Ha a háttérben futtatod a szála(ka)t, akkor viszont soha nem fog kiderülni (vagy csak vért izzadás árán) az ellenkezője. Tehát nem/nehezebben jössz rá, hogy mégsem úgy működik valami, ahogy eltervezted.
    Nem pont erre asszociáltam debugolás kapcsán, de azt hiszem, értem mire gondolsz.
    Adott esetben nem feltétlenül van jelentősége, hogy a thread hogy ért véget, mert pl. épp csak monitorozott valamit és nem érdekes, hol állt meg, vagy a gui thread nélkül nincs is értelme tovább futnia, vagy hosszan fut egy-egy tevékenység benne, és nincs idő megvárni, amíg rájön, hogy le kell állnia. Mit csináljon, várjon egy percet amíg befejezi (remélhetőleg) és eljut a következő szálban maradási ellenőrzésig? De lehet, hogy a felhasználó nem szeretné megvárni, hanem kikapcsolja a gépet, és végül fogalmunk sem lenne így sem, hogy mi történt. Vagy pedig ilyen esetben engeded kimúlni background threadként, és lekezeled a threadabortexceptiont és kilogolod a megfelelő infókat.
    No de visszakanyarodva az eredeti kérdésre, ha más lett volna a kontextus, akkor nem az isBackgroundot ajánlom elsőkörben. A kérdésből úgy tűnt, hogy nem cél kontrollálni a threadet, nem cél bármi cleanupot elvégezni, csak pusztuljon a szál a processzel együtt - mivel eleve csak akkor merült fel az egész kérdés, mikor már kiderült, hogy valami nem klappol, nem áll le a processz. Persze ez lehet, hogy a körültekintés hiányából fakad, és nem tudatos.

Új hozzászólás Aktív témák

Hirdetés