[win32] PostThreadMessage =&gt; GetLastError() geeft 183 terug

woensdag 12 maart 2003 09:26

Topicstarter

Ik zit met het volgende probleem:
Ik heb een win32 thread die er als volgt uit ziet:

C++:

DWORD WINAPI WorkerProc(LPVOID lpParameter)
{
  while (GetMessage(&mMsg, NULL, 0, 0))
  {
    switch (mMsg.message)
    {
      case MY_MSG_ID:
        // Doe dingetjes
        break;
      // etc, etc
    }
  }
}

Dit is dus een thread met een message-queue. Naar deze thread stuur ik messages als volgt:

C++:

1	PostThreadMessage(dwThreadID, MY_MSG_ID, wParam, lParam);

De applicatie waar deze thread in draait is een app die continue, 24 uur per dag, 7 dagen per week moet draaien.
Dit gaat heel lang goed, maar op een gegeven moment begint PostThreadMessage fout te gaan (dit duurt wel een paar dagen voordat het gebeurt). GetLastError() geeft dan code 183 terug (FormatMessage() geeft vervolgens "Cannot create a file when that file already exists.").
Als ik op google zoek, dan vind ik wel meldingen van deze error, maar niet in combinatie met PostThreadMessage. Iemand een idee wat de oorzaak van deze error zou kunnen zijn?

Acties:

left part of the evil twins

Idd die errormsg klopt in 95% van de gevallen, maar de officiele naam voor 183 is ERROR_ALREADY_EXISTS. Deze error wordt niet alleen gegeven als een file al bestaat maar in het algemeen als een doel van een operatie al bestaat.

Ik ken de symptomen die je noemt verder niet (klinkt als een bug, welk OS gebruik je?). Sowieso, heeft die thread een message queue omdat ie een window heeft? Zo ja kun je ook direct naar dat window posten met PostMessage voor hetzelfde resultaat.

woensdag 12 maart 2003 09:31

Acties:

left part of the evil twins

Things to check:
• Als je de error negeert gaat ie dan de volgende keer wel goed?
• Is het mogelijk dat de message queue vol is door spam en/of starvation?

Ik zou in het 2e geval de error nl. gerechtvaardigd vinden.

woensdag 12 maart 2003 09:34

Acties:

woensdag 12 maart 2003 09:37

Topicstarter

Hmm, sorry, ik ben misschien niet helemaal duidelijk geweest

. Dit is een standalone thread die niet met een window ge-associeerd is. De message-queue wordt aangemaakt doordat ik de GetMessage() functie aanroep.
Ik gebruik Windows 2000 Server.

Acties:

woensdag 12 maart 2003 09:39

Topicstarter

curry684 schreef op 12 March 2003 @ 09:31:
Things to check:
• Als je de error negeert gaat ie dan de volgende keer wel goed?
• Is het mogelijk dat de message queue vol is door spam en/of starvation?

Ik doe het sturen zoals in de MSDN library staat aangegeven. Als PostThreadMessage failed, dan ff Sleep()-en en vervolgens nog eens proberen. Dat doe ik net zolang tot het wel lukt.
Het zou idd goed mogelijk kunnen zijn dat de message queue vol is. De oorzaak daarvan zou ik alleen echt niet weten. Zou je misschien kort kunnen uitleggen wat de oorzaken van spam en/of starvation zijn (en wat starvation precies is)?

Acties:

yodax

Ik ben het ook met curry684 eens. Waarschijnlijk loopt je message queque over. Dit is erg vreemd omdat je deze continu leegt. Het correspondeerd echter wel met je fout melding.

Je zou kunnen proberen met PeekMessage of er nog meer berichten klaar staan als je GetMessage gedaan hebt.

En kijk na de error eens of er nog berichten staan.

woensdag 12 maart 2003 09:42

Acties:

yodax

Thread starvation houd in dat je thread geen cpu tijd meer krijgt doordat je applicatie alle cpu tijd voor zichzelf claimt.

Als ik een loop in de hoofd applicatie heb zet ik er altijd even een sleep(0) tussen. Deze geeft de controle van de huidige thread weg aan een andere thread.

woensdag 12 maart 2003 10:00

Acties:

woensdag 12 maart 2003 10:16

Topicstarter

Het lijkt me sterk dat deze thread geen cpu tijd krijgt, want de processorload (in task manager) komt nooit boven de 50% uit als mijn applicatie draait. Ook zou het probleem zich dan eerder moeten voordoen (het duurt nu ongeveer 5 dagen voordat het probleem optreedt).
Ik heb nu de code van de thread enigszins aangepast (nog eens goed naar de MSDN documentatie van GetMessage gekeken):

C++:

DWORD WINAPI WorkerProc(LPVOID lpParameter) 
{
  BOOL bRet;
  MSG  mMsg;

  while ((bRet = GetMessage(&mMsg, NULL, 0, 0)) != 0) 
  {
    if (bRet == -1)
    {
      // Handel fout af
    } else
    {
      switch (mMsg.message) 
      { 
        case MY_MSG_ID: 
          // Doe dingetjes 
          break; 
        // etc, etc 
      } 
    }
  } 
}

Ik denk niet dat dit een oplossing van het probleem is, maar als GetLastError inderdaad fouten geeft, ben ik iig misschien wat dichter bij de oorzaak van het probleem. Dit gaat waarschijnlijk weer ongeveer 5 dagen duren voor het probleem zich voordoet, maar in de tussentijd blijven suggesties uiteraard welkom

Acties:

left part of the evil twins

Wortelpudding schreef op 12 March 2003 @ 09:37:
Zou je misschien kort kunnen uitleggen wat de oorzaken van spam en/of starvation zijn (en wat starvation precies is)?

Kort samengevat doelde ik op of het mogelijk is dat je sneller messages genereert dan dat de thread ze kan parsen.

Dit kan zijn doordat er higher priority threads rondlopen die de thread starven of doordat je gewoon enorm veel messages post en je systeem op 100% cpu load zit (spam).

Nog een mogelijkheid die me net te binnen schoot: PostThreadMessage moet intern synchronizeren, en naar ik hoogste waarschijnlijkheid via een mutex. De functie CreateMutex kan indien named gebruikt de error ERROR_ALREADY_EXISTS teruggeven. Dit zou een logische verklaring zijn voor een bug binnen windows.

yodax schreef op 12 March 2003 @ 09:42:
Als ik een loop in de hoofd applicatie heb zet ik er altijd even een sleep(0) tussen. Deze geeft de controle van de huidige thread weg aan een andere thread.

Niet nodig in dit geval, GetMessage doet impliciet een sleep. Daardoor kan een process met message queue nooit het OS al te hard pesten.

woensdag 12 maart 2003 10:37

Acties:

left part of the evil twins

Wortelpudding schreef op 12 maart 2003 @ 10:00:
Het lijkt me sterk dat deze thread geen cpu tijd krijgt, want de processorload (in task manager) komt nooit boven de 50% uit als mijn applicatie draait. Ook zou het probleem zich dan eerder moeten voordoen (het duurt nu ongeveer 5 dagen voordat het probleem optreedt).

Is de server host voor meerdere apps zoals IIS, SQL Server etc.? Zo ja is het mogelijk dat er grote performancespikes eens per paar dagen optreden (denk aan backup jobs!!!)?

Hoevaak per seconde post je een message? Is het binnen je applicatie mogelijk om de messagethread een thread priority van THREAD_PRIORITY_ABOVE_NORMAL te geven?

woensdag 12 maart 2003 10:51

Acties:

woensdag 12 maart 2003 11:05

Topicstarter

De thread die de messages stuurt heeft inderdaad een hogere prioriteit dan de ontvangende thread. In onze testomgeving stuurt hij ongeveer 240 messages per seconde.
Maar nogmaals: de processor performance is normaal 50%. Wat ik nog niet vermeld had is dat er 1x per uur een korte piek naar 100% komt, om vervolgens weer netjes naar 50% terug te vallen.

Acties:

left part of the evil twins

Wortelpudding schreef op 12 March 2003 @ 10:51:
De thread die de messages stuurt heeft inderdaad een hogere prioriteit dan de ontvangende thread. In onze testomgeving stuurt hij ongeveer 240 messages per seconde.
Maar nogmaals: de processor performance is normaal 50%. Wat ik nog niet vermeld had is dat er 1x per uur een korte piek naar 100% komt, om vervolgens weer netjes naar 50% terug te vallen.

OUCH.

Helaas kan ik nergens vinden hoe groot een message queue normaal is, maar ik vind wel dit stukje in de Platform SDK:

A common programming error is to assume that the PostMessage function always posts a message. This is not true when the message queue is full. An application should check the return value of the PostMessage function to determine whether the message has been posted and, if it has not been, repost it.

Ik denk dat je welzeker een overflow genereert. Ik vind het sowieso erg twijfelachtig dat de senderthread een hogere prioriteit heeft dan de receiver, dit lijkt me een enorme fout. Ik zou er voor zorgen dat ze gelijk zitten....

donderdag 13 maart 2003 08:47

Acties:

donderdag 13 maart 2003 10:02

Topicstarter

Ok, de zendende en de ontvangende thread hebben nu dezelfde prioriteit. Ook heb ik (zoals gezegd in een paar posts geleden) error checking aan GetMessage() toegevoegd. Ook doe ik error checking op PostThreadMessage().
Toch is het probleem vannacht weer opgetreden

De message-queue van een thread/window is standaard 10000 messages (zie MSDN documentatie bij PostThreadMessage). Als ik even reken concludeer ik dat de ontvangende thread dus 41.6 seconden stil moet liggen (bij 240 messages/sec) om de message-queue te laten vollopen (de verzendende thread zal altijd continue messages blijven sturen). Het kan natuurlijk ook zo zijn dat de verzendende thread 240 msg's/sec stuurt terwijl de ontvangende bijvoorbeeld 220 msg's/sec afhandelt, dan stapelt het zich langzaam op.

Dit ga ik nu maar eens onderzoeken... Verdere suggesties/opmerkingen/oplossingen blijven natuurlijk welkom

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

mag ik vragen wat je dan precies aan het zenden bent, en waarom je daar 240 messages per seconde voor nodig hebt?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 maart 2003 10:18

Acties:

donderdag 13 maart 2003 10:26

Topicstarter

.oisyn schreef op 13 March 2003 @ 10:02:
mag ik vragen wat je dan precies aan het zenden bent, en waarom je daar 240 messages per seconde voor nodig hebt?

Maar natuurlijk

.
Het is een audiologging applicatie. De verzendende thread ontvangt messages van de Multimedia SDK (MM_WIM_DATA) als er een buffer met audio beschikbaar is. Deze thread kopieert ze (en splitst zonodig links en rechts) en stuurt ze door naar de ontvangende thread zodat ze asynchroon afgehandeld kunnen worden (gecomprimeerd naar WMA/MPEG/etc en weggeschreven naar een file).
In de testomgeving wordt van 12 stereo audio inputs tegelijk opgenomen. De audiobuffers worden in de verzendende thread gesplitst in separate buffers voor links/rechts (dus dat worden dan uiteindelijk 24 buffers) en deze buffers worden naar de ontvangende thread gestuurd. De buffergrootte is ingesteld op 1/10 seconde, dus 24 * 10 = 240 messages per seconde

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

mja, ik kan me voorstellen dat als je 24 buffers moet gaan comprimeren dat je pc dat niet meer in real time trekt, en je message queueu dus langzaam vol raakt

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 maart 2003 10:29

Acties:

donderdag 13 maart 2003 10:33

Topicstarter

.oisyn schreef op 13 March 2003 @ 10:26:
mja, ik kan me voorstellen dat als je 24 buffers moet gaan comprimeren dat je pc dat niet meer in real time trekt, en je message queueu dus langzaam vol raakt

Hmmm, ook als je testsysteem een dual-xeon 2.40GHz met hyperthreading is? (nog maar es een keer: processor-load is 50%, dat lijkt me niet te hoog).

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

En dan wordt het gelijk duidelijk waarom de load 50% is. Je gebruikt 1 thread, en dus maar 1 processor. Als je het wil verdelen zul je meerdere threads moeten laten draaien. Die ene cpu wordt dus volop benut, terwijl die andere uit z'n neus staat te vreten

(zitten er trouwens echt 2 fysieke cpu's in, met beide hyperthread support (dus effectief 4 cpu's), of is het gewoon 1 cpu met hyperthread support en dus effectief 2 cpu's?)

[ Voor 11% gewijzigd door .oisyn op 13-03-2003 10:33 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 maart 2003 10:38

Acties:

left part of the evil twins

Wortelpudding schreef op 13 March 2003 @ 08:47:
Ok, de zendende en de ontvangende thread hebben nu dezelfde prioriteit. Ook heb ik (zoals gezegd in een paar posts geleden) error checking aan GetMessage() toegevoegd. Ook doe ik error checking op PostThreadMessage().
Toch is het probleem vannacht weer opgetreden

Helaas, ik had gehoopt dat dit wel zou helpen.

Het blijft moeilijk om zonder de volledige code te zien een goede analyse te maken

De message-queue van een thread/window is standaard 10000 messages (zie MSDN documentatie bij PostThreadMessage).

Duh, 10 keer overheen gelezen

Het kan natuurlijk ook zo zijn dat de verzendende thread 240 msg's/sec stuurt terwijl de ontvangende bijvoorbeeld 220 msg's/sec afhandelt, dan stapelt het zich langzaam op.

Dit is het vermoeden dat ik ook had, echter dit zou bij gelijke prioriteit niet op mogen treden als er niet enkele minuten lang 100% CPU-load is.

Wortelpudding schreef op 13 March 2003 @ 10:18:
Het is een audiologging applicatie. De verzendende thread ontvangt messages van de Multimedia SDK (MM_WIM_DATA) als er een buffer met audio beschikbaar is. Deze thread kopieert ze (en splitst zonodig links en rechts) en stuurt ze door naar de ontvangende thread zodat ze asynchroon afgehandeld kunnen worden (gecomprimeerd naar WMA/MPEG/etc en weggeschreven naar een file).
In de testomgeving wordt van 12 stereo audio inputs tegelijk opgenomen. De audiobuffers worden in de verzendende thread gesplitst in separate buffers voor links/rechts (dus dat worden dan uiteindelijk 24 buffers) en deze buffers worden naar de ontvangende thread gestuurd. De buffergrootte is ingesteld op 1/10 seconde, dus 24 * 10 = 240 messages per seconde .

Ik zou dit persoonlijk op een compleet andere manier oplossen, namelijk met een synchronized queue. Dit houdt in dat je een speciale 'BufferFifoStack' class maakt met 2 methods Push en Pop en een member Mutex/CriticalSection. De beide methods locken die mutex, de Push plaatst een buffer aan het einde van de lijst en de Pop verwijdert er een vooraan de lijst. De readerthread gebruikt de Push, de mainthread de Pop.

Op deze manier ben je alleen gelimiteerd door de heap, en als je daar doorheen loopt kan de computer je applicatie gewoon niet aan

Mocht de compressie echt pijnlijk traag zijn kun je zelfs met een extra queue werken:
• Audiothread post z'n pakketjes linea recta in Queue A en gaat verder met audio lezen.
• Compressiethread trekt deze pakketjes er in z'n eigen tempo uit, comprimeert ze en plaats ze in Queue B.
• Main thread trekt de pakketjes uit Queue B zodra ze beschikbaar zijn.

Op deze manier zal je nooit audiobuffer overflows krijgen en blijft de main thread responsive omdat het feitelijke werk in een aparte thread gedaan wordt en de andere 2 niet zullen hangen als er geen data beschikbaar is voor ze. Ik zou je zelf aanraden de compressiethread op BELOW_NORMAL priority te zetten zodat ie de andere 2 niet in de problemen kan brengen.

Ik hoop dat je hier iets mee kan

donderdag 13 maart 2003 10:42

Acties:

KnoppenSpook

En als de compressie nou langer duurt dan het volgende audio sample weer binnen komt?
Dan heb je imo een oneindig grote buffer nodig, aangezien dit systeem 24/7 moet draaien...

/me weet geen leuke quote voor in zijn signature

donderdag 13 maart 2003 10:43

Acties:

left part of the evil twins

Wortelpudding schreef op 13 maart 2003 @ 10:29:
[...]
Hmmm, ook als je testsysteem een dual-xeon 2.40GHz met hyperthreading is? (nog maar es een keer: processor-load is 50%, dat lijkt me niet te hoog).

Ah, dit had ik nog niet gezien bij m'n vorige post

Als je de applicatie geil wil laten werken op veel-CPU-systemen kun je zelfs een pool aanmaken met compressorthreads die allemaal uit dezelfde queue rapen. Let er wel op dat je op de goede plek de mutexes lockt (alleen tijdens het managen van de lijst, NIET tijdens compressie!!!) en dit werkt perfect.

Ik heb op deze manier overigens zowel Remote Desktop als Voice&Video systemen geschreven, dus ik kan bij deze garanderen dat deze approach perfect werkt

donderdag 13 maart 2003 10:44

Acties:

left part of the evil twins

KnoppenSpook schreef op 13 March 2003 @ 10:42:
En als de compressie nou langer duurt dan het volgende audio sample weer binnen komt?
Dan heb je imo een oneindig grote buffer nodig, aangezien dit systeem 24/7 moet draaien...

Ik zei dus:

Op deze manier ben je alleen gelimiteerd door de heap, en als je daar doorheen loopt kan de computer je applicatie gewoon niet aan

Er zijn nu eenmaal fysieke limieten waar je tegenaan kunt lopen. Maar dit treedt alleen op als de server constant 100% CPU-load heeft. Een spike van meerdere minuten is zo probleemloos af te vangen.

donderdag 13 maart 2003 11:17

Acties:

KnoppenSpook

Daar heb je idd gelijk in!

Wat background informatie over Multimedia Apps en HyperThreading.
Wellicht interessant:
http://www.osnews.com/story.php?news_id=3023

[ Voor 11% gewijzigd door KnoppenSpook op 13-03-2003 11:18 ]

/me weet geen leuke quote voor in zijn signature

donderdag 13 maart 2003 11:24

Acties:

left part of the evil twins

KnoppenSpook schreef op 13 March 2003 @ 11:17:
Daar heb je idd gelijk in!

Zelfs fysieke limieten zijn relatief trouwens. Niemand die je tegenhoudt om te stellen dat je packets gaat truncen zodra er 50000 of zo in de queue staan. Tis een geschifte hoeveelheid die alleen in geschifte situaties optreedt, maar die dan wel voorkomt dat je je hele systeem opknupt zonder geheugen.

Is ook een handige safeguard tegen bugs van jezelf, zou lullig zijn als je door een typfout de Exchange/IIS/SQL server van je bedrijf moet rebooten

vrijdag 14 maart 2003 17:09

Acties:

left part of the evil twins

<genadeloze schop/>

Ik ben wel erg benieuwd naar de resultaten... MrHuge?

maandag 17 maart 2003 08:56

Acties:

maandag 17 maart 2003 09:45

Topicstarter

curry684 schreef op 14 March 2003 @ 17:09:
<genadeloze schop/>
Ik ben wel erg benieuwd naar de resultaten... MrHuge?

LOL, nou, we hebben de testen nog wat uitgebreid en de oorzaak lijkt toch ergens anders te liggen als wat ik aanvankelijk dacht.

We hebben nu ook perfon draaien met wat monitors voor harddisk performance.
Ik was overigens vergeten om nog een detail te vermelden: als de PostThreadMessage aan het misgaan is, dan is de processor-load erg laag (maar een paar procent). Het lijkt er dan dus ook op dat de ontvangende thread z'n binnenkomende messages op dat moment erg langzaam aan het afhandelen is. Wat we nu zien is dat, op het moment dat de ontvangende thread heel langzaam aan het afhandelen is, de harddisk ineens een behoorlijke 'usage' piek heeft.
Het lijkt er dus op dat op dat moment de harddisk het zo druk heeft dat de gecomprimeerde audio die naar de files moet worden weggeschreven niet snel genoeg weggeschreven kan worden.

In het systeem zit een SCSI RAID controller (Dell CERC ATA100/4ch RAID Controller). In deze testsituatie worden continue 24 files met een bitrate van 32 kbit/sec tegelijk geschreven. Elk uur wordt er een nieuw bestand aangemaakt.

Ik denk dus dat we de oorzaak van het probleem eerder bij het plotseling extreem oplopen van de harddisk-performance moeten zoeken, dan bij de beperkte message-queue van de ontvangende thread (alhoewel we curry684 z'n zeer goede suggestie over de synchronized FIFO hoogst waarschijnlijk ook zullen gaan implementeren).

Acties:

left part of the evil twins

Wortelpudding schreef op 17 March 2003 @ 08:56:
(alhoewel we curry684 z'n zeer goede suggestie over de synchronized FIFO hoogst waarschijnlijk ook zullen gaan implementeren).

Daar het een correcte oplossing is voor alle performance-spikes, dus ook HD-pieken, lijkt me dat wel handig ja

Let wel: als je vermoed dat de HD-usage een probleem is krijg je de volgende priorityverdeling:
• Mainthread NORMAL
• Compressorthread BELOW_NORMAL
• Extractiethread ABOVE_NORMAL

maandag 17 maart 2003 10:04

Acties:

maandag 17 maart 2003 10:40

Topicstarter

curry684 schreef op 17 maart 2003 @ 09:45:
Daar het een correcte oplossing is voor alle performance-spikes, dus ook HD-pieken, lijkt me dat wel handig ja

Behalve als die pieken af en toe wel zo'n 10 minuten kunnen duren

, dan ga je toch zowieso audiosamples verliezen, en da's niet de bedoeling

(10 minuten * 60 seconden * (32000 Hz * 2 bytes/sample) * 24 kanalen = 879 megabyte intern geheugen opgeslokt).
Ik heb het vermoeden dat de oplossing eerder bij het probleem van de harddisk ligt. Het zou natuurlijk iets met een probleem met write-behind caching ofzo te maken kunnen hebben.
Ik comprimeer en schrijf de files met behulp van de Windows Media Format SDK 7.1, dus helaas weet ik niet met wat voor flags (CreateFile) de files precies geopend worden.

Acties:

maandag 17 maart 2003 12:27

Net een klein test (delphi) progje gemaakt om te zien wat er mis gaat bij een message queue overflow. Volgens win32 API

Windows 2000/XP: There is a limit of 10,000 posted messages per message queue

Het volgende test programma stopt dan ook precies bij 10000 messages in the queue. GetLastError geeft dan 1444 ( ERROR_INVALID_THREAD_ID ). Volgens API is dat het geval wanneer

if idThread is not a valid thread identifier, or if the thread specified by idThread does not have a message queue

Dus windows rapporteert geen queue wanneer de message queue vol zit. Ik heb dit getest op win2000 prof sp3. Ik denk dus dat jij een ander probleem hebt dan het vol zitten van de queue. Zou dus zoals curry zegt een bug in windows kunnen zijn hoewel ik zelf er eerst altijd vanuit ga dat ik zelf iets verkeerd doe.

code:

  TMyThread = class( TThread )
    procedure Execute; override;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}


procedure TMyThread.Execute;
var
  Msg : TMsg;
begin
  while GetMessage( Msg, 0, 0, 0 ) do
  begin
    sleep( 4000000000 );
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  MyThread  : TMyThread;
  Res       : Boolean;
  NrSent    : Integer;
begin
  NrSent := 0;
  MyThread := TMyThread.Create( False );
  while not PostThreadMessage( MyThread.ThreadID, WM_USER, 0, 0 ) do;
  repeat
    Res := PostThreadMessage( MyThread.ThreadID, WM_USER, 0, 0 );
    if Res = True then Inc( NrSent );
  until Res = False;
  ShowMessage( Format( 'LastError: %d, Messages Sent: %d', [ GetLastError, NrSent ] ) );
end;

Acties:

left part of the evil twins

Wortelpudding schreef op 17 March 2003 @ 10:04:
[...]
Behalve als die pieken af en toe wel zo'n 10 minuten kunnen duren , dan ga je toch zowieso audiosamples verliezen, en da's niet de bedoeling (10 minuten * 60 seconden * (32000 Hz * 2 bytes/sample) * 24 kanalen = 879 megabyte intern geheugen opgeslokt).

Ah.....

Of je koopt een nieuwe harddisk

maandag 17 maart 2003 13:15

Acties:

maandag 17 maart 2003 13:17

misschien een overbodige vraag maar ik stel hem toch. Roep je GetLastError wel aan in dezelfde thread als waar je de PostThreadMessage doet? dwz zoiets als

code:

Res = PostThreadMessage(dwThreadID, MY_MSG_ID, wParam, lParam);

if ( Res == FALSE ) {
  LastError = GetLastError();
}

Acties:

maandag 17 maart 2003 14:28

Topicstarter

TijnFLiP schreef op 17 March 2003 @ 13:15:
misschien een overbodige vraag maar ik stel hem toch. Roep je GetLastError wel aan in dezelfde thread als waar je de PostThreadMessage doet?

Acties:

maandag 17 maart 2003 14:33

Wat is de msg Id van MY_MSG_ID ? dwz welke waarde gebruik je daarvoor?

Acties:

maandag 17 maart 2003 14:58

Topicstarter

TijnFLiP schreef op 17 maart 2003 @ 14:28:
Wat is de msg Id van MY_MSG_ID ? dwz welke waarde gebruik je daarvoor?

MM_WIM_DATA (van de Microsoft Multimedia SDK).

Acties:

maandag 17 maart 2003 15:03

Ik heb geen ervaring met MMSDK maar ik zie dat bijv

waveInOpen

ook als 'callback' een thread ID kan hebben zodat de messages daar naartoe worden gestuurd. Waarom gebruik jij PostThreadMessage in niet dat principe? Het zou nl kunnen dat je een race conditie hebt doordat je in twee threads tegelijk hetzelfde multimedia device accessed.

Acties: