[Delphi/Kylix] Blocking thread afsluiten

[Verwijderd]

Ik heb een main applicatie. Binnen de main applicatie wordt een instantie van de THardwareHandling classe aangemaakt.

In de constructor van deze classe wordt vervolgens weer een THardwareInterruptHandling instantie aangemaakt. THardwareInterruptHandling is gebaseerd op TThread.

In de OnExecute van deze instantie wordt een blocking methode aangeroepen (die dus pas iets terug geeft als er een interrupt ontstaan is of dat de timeout verstreken is).

Stel nu dat er een hele lange timeout meegegeven wordt en dat er geen interrupt ontstaat. De thread staat dan dus in "blocking mode".

Nu moet de main applicatie afgesloten worden. De THardwareHandling instantie zal vervolgens weer vrijgegeven worden.

Maar hoe zit dat met de THardwareInterruptHandling klasse (die dus in blocking mode is). Ik neem aan dat je niet de instantie van deze classe met Free kan beeindigen?

[curry684]

Jawel hoor, en die zal een enorme Access Violation geven. Gewoon korte timeout gebruiken dus en TThread::WaitFor() aanroepen.

[Verwijderd]

curry684 schreef op 10 July 2003 @ 14:30:Gewoon korte timeout gebruiken dus en TThread::WaitFor() aanroepen.

Is er echt geen andere methode?

[ Voor 3% gewijzigd door Verwijderd op 10-07-2003 15:13 ]

[curry684]

Buiten de enorm ranzige TerminateThread niet, en waarom voldoet deze niet?

[elevator]

Kan je niet op 2 events gaan blocken (dmv WaitForMultipleObjects) zodat je een event zelf kan enablen op het moment dat je je thread wil onderbreken?

[Verwijderd]

elevator schreef op 10 July 2003 @ 16:15:
Kan je niet op 2 events gaan blocken (dmv WaitForMultipleObjects) zodat je een event zelf kan enablen op het moment dat je je thread wil onderbreken?

Ik werk onder linux en volgens mij is WaitForMultipleObjects een windows functie

[elevator]

Klopt

Hoe block je in Kylix dan?
Dmv select() ofzo? Zo ja - kan je ook daarmee selecten op meerdere blocking fd's

[curry684]

Je hebt helemaal geen event nodig. TThread heeft een Terminating flag, en die kun je vanuit de parentclass zetten met 'Terminate'. De thread zelf doet een while(!Terminating) en binnen die loop steeds de hardware checken met een timeout van 5ms of zo. De aanroeper is dus als volgt klaar:

C++:

MyThread->Terminate();
MyThread->WaitFor();

[elevator]

Denk je niet dat het mooier is om dmv. een echte blocking functie blokken, dan door middel van een loopje een block te simuleren ?

[curry684]

In de eerste post:

In de OnExecute van deze instantie wordt een blocking methode aangeroepen (die dus pas iets terug geeft als er een interrupt ontstaan is of dat de timeout verstreken is).

Uit die omschrijving begrijp ik dat hij geen invloed heeft op het wachtproces van die functie zelf.

[elevator]

Ik kan het niet uit de TS halen - maar de TS kan hier wel uitsluitsel over geven ?

[curry684]

Bovendien is er niets mis met een close loop om een kernelmode wait, kost weinig tot geen extra CPU-tijd.

[elevator]

curry684 schreef op 10 juli 2003 @ 17:07:
Bovendien is er niets mis met een close loop om een kernelmode wait, kost weinig tot geen extra CPU-tijd.

Ofdat het nou weinig of veel uitmaakt - je kiest toch - waar mogelijk - voor de meest mooie oplossing? Een loopje - ipv een blocking wait is toch minder mooi ?

[Verwijderd]

Hoe het precies zit met de interrupt generatie, weten we nog niet, omdat dat gedeelte nog niet opgeleverd is door degene die dit aan het maken is.

Maar het nadeel van een lage timeout waarde is, dat je dus continu in de execute aan het "loopen" bent. Eigenlijk is dat niet nodig. Wij willen tenslotte alleen maar een reactie hebben als er een interrupt ontstaan is.

(Trouwens de blocking methode aanroep gebeurt via ioctl(FileDescriptio, IOCTL_CODE, .....))


In ons geval gaat het eigenlijk om een dedicated systeem. Er zit geen toetsenbord, monitor en muis op aangesloten. Als het programma wordt afgesloten betekent dat altijd dat de computer uitgezet wordt.

Nu zijn er wel een paar "ranzige" oplossingen die we ervoor zouden kunnen gebruiken.

Bijv gewoon met Free, maar dan in een try...except en vervolgens de error gewoon negeren. Of gewoon aan het OS over laten die bij het uitzetten het proces uiteindelijk zal killen.

Ja ik weet het zijn hele smerige opties, maar goed in princiepe willen wij echt zo lang mogelijke timeout waarde meegegeven aan die functie die bij een interrupt pas iets teruggeeft. (Het liefste hadden we helemaal geen timeout waarde mee willen geven, alleen dat moet nu eenmaal wel).