est-il correct de supposer que GetLasterRor (et des variantes) sont par threads ou est-il pertratif? Les problèmes que si le processus est par traitement sont quelque peu évidents dans des applications multithreadées car il n'ya aucun moyen de garantir qu'aucun autre appel Win32 n'a été fait entre votre appel et votre getlasterror défaillant. Parfois, la valeur de GetLasterRor est importante.
Par exemple, AcceptEx retournera FALSE (échec) si vous utilisez des ports d'achèvement IO. Wsagetlasterror (similaire à getlasterror) retournera erron_io_pending pour vous informer qu'il est suspendu et que l'échec n'est pas due à autre chose. Le problème est que des dizaines d'appels peuvent être en vol et écraser cette valeur.
Ces appels sont-ils spécifiques ou processus spécifiques? Si spécifique au processus, comment gérez-vous cela correctement?
3 Réponses :
Les deux getlasterror et wsagetlasterror renvoient des codes d'erreur par thread. Regardez les entrées MSDN:
Les docs sont absolument sans ambiguïtés à ce sujet. :
fonction getlasterRor
récupère le fil d'appel dernière valeur de code d'erreur. La dernière erreur le code est maintenu sur un par thread base. Les threads multiples ne font pas écrase la dernière erreur de chacun code.
Alors ils l'ont dit trois fois (dans un seul paragraphe!): devrait suffire, comme Lewis Carroll < / a> dit ;-). Ainsi, il n'y a pas besoin de répondre à des hypothèses telles que "mais si elle était pertra-traitement plutôt que par fil, alors qu'en est-il de ...?"; -).
Je dois être aveugle parce que je ne l'ai pas vu dans les documents MSDN tant que tout le monde l'a signalé.
Vous pouvez lire sur MSDN (voir http://msdn.microsoft. COM / EN-US / Bibliothèque / MS679360.aspx ) Réponse claire sur votre question:
récupère le fil d'appel dernière valeur de code d'erreur. La dernière erreur le code est maintenu sur un par thread base. Les threads multiples ne font pas écrase la dernière erreur de chacun code.