kleine rätselfrage: warum funktioniert dieser code nicht?

[Jochen Kalmbach]

Es ist natürlich auch miserabel den Rückgabewert nicht zu prüfen... wenn das Handle nicht genügend Rechte hat, gibt es auch Probleme...

[net 0]

Hallifax schrieb:

es könnte auch TerminateThread(threadhandle,STILL_ACTIVE) sein

nein, es werden keine faulen tricks verwendet. die threadfunction sieht ungefähr so aus

DWORD thread (DWORD param)
{
   for (;;)
   {
      if (stop_the_thread == TRUE)
         return 0;
     // hier etwas anderer code
     // ohne return, ExitThread() und dergleichen
   }
}

[net 0]

Jochen Kalmbach schrieb:

Es ist natürlich auch miserabel den Rückgabewert nicht zu prüfen... wenn das Handle nicht genügend Rechte hat, gibt es auch Probleme...

leider auch nicht. das handle wird vom gleichen prozess erzeugt. rückgabewert direkt von CreateThread()... und der thread wird auch gestartet d.h. handle ist gültig, nicht INVALID_HANDLE_VALUE oder sowas

[Jochen Kalmbach]

Dann hast Du zumindest Deine Threadproc falsch angegeben (hier fehlt ein WINAPI; ganz abgesehen davon, dass der übergabeparameter auch falsch deklariert ist (müsste LPVOID sein)).

[net 0]

Jochen Kalmbach schrieb:

Dann hast Du zumindest Deine Threadproc falsch angegeben (hier fehlt ein WINAPI).

sorry, das hatte ich vergessen. im original steht da noch ein __stdcall. doch auch wenn ich es wegnehme ändert das nichts an dieser misteriösen endlosschleife

[Ominion]

Es heißt mysteriös. . Aber los du Ratefuchs, sag uns die Lösung!

Mfg Ominion

[Hallifax]

In meiner Doku steht noch was:

Note This API is part of the complete Windows CE OS package as provided by Microsoft. The functionality of a particular platform is determined by the original equipment manufacturer (OEM) and some devices may not support this API.

[MFK]

Hallifax schrieb:

In meiner Doku steht noch was:

Ich glaube, du hast da die falsche Doku. net hat jedenfalls nichts davon gesagt, dass der CE benutzt.

[Hallifax]

naja, vielleicht ist das ja das Problem...

[net 0]

Ominion schrieb:

Es heißt mysteriös. . Aber los du Ratefuchs, sag uns die Lösung!

okay, so gehts:

stop_the_thread = TRUE; 
volatile DWORD exitcode = STILL_ACTIVE; 
while (exitcode == STILL_ACTIVE) 
   GetExitCodeThread (threadhandle, (DWORD*)&exitcode);

seltsam? nicht wahr?

[Ominion]

Das muss ich aber nicht verstehen oder?

Mfg Ominion

[ominions oma]

toll wenn der compiler andere einstellungen hat und anders optimiert kann das aber auch ned auftreten müssen, die frage war von anfang an dumm

[Ominion]

Danke Oma. Dank dir habe ich jetzt den Durchblick was Sache ist.

Mfg Ominion

[ominions oma]

wenn du einmal ein buch lesen würdest wüsstest du das volatile sicherstellt daß variablen werte immer aus dem speicher in die register geladen werden was sonst wegen optimierungen nicht immer gemacht werden muss

[Jochen Kalmbach]

In diesem Fall wäre es aber ein Compiler-Bug... da die veränderung ja im gleichen Thread stattfindet...

[net 0]

Jochen Kalmbach schrieb:

In diesem Fall wäre es aber ein Compiler-Bug... da die veränderung ja im gleichen Thread stattfindet...

gut erkannt!
ich verwende ein relativ altes visual studio,
compiler: version 13.00.9466
war bisher eigentlich recht zuverlässig, das teil. aber vielleicht weigert er sich auch nur miesen code zu compilen. schliesslich macht man sowas ja mit WaitForSingleObject

[Ominion]

@oma: Meine Mathebücher haben mir das aber nicht gesagt! Wie Jochen das so schön gesagt hat:

Jochen Kalmbach schrieb:

In diesem Fall wäre es aber ein Compiler-Bug... da die veränderung ja im gleichen Thread stattfindet...

Ich werde mich jetzt auch nicht weiter zu diesem Thema äußern, da die Gefahr besteht, dass das in einer Endlosschleife endet.

Mfg Ominion