http://msdn.microsoft.com/en-us/library/zyzhdc6b.aspx스레드가 다른 핸들을 소유 할 수 있습니까?
컨트롤의 내부 창 핸들이 들어있는 스레드에서 지정된 대리자를 실행합니다.
MSDN 문서에 따르면 thread은 다른 핸들을 소유 할 수 있습니다.
내 추측은 thread 다른 handles도 참조 할 수있는 handle으로, 특별한 슈퍼 kernel object 때문이다?
같은 :
핸들 | 스레드 핸들 참조
3201 | 20
4882 | 20
4827 | 7
이 경우 yes입니다.
기본적으로 Windows GUI의 배경에는 Windows OS (마우스, 키보드 및 기타 입력 하드웨어에 대해 잘 알고있는)와 프로그램 (사용자 인터페이스에 대해 알지 못하는) 사이의 양방향 통신 인 "메시지 루프" 구체적인 사항을 알 필요는 없지만 이러한 입력 장치를 기반으로하는 앱 내에서 사용자 입력에 반응해야합니다. 이 루프를 유지하고 Windows에서 프로그램으로 들어오는 메시지를 수신하고 다양한 GUI 컨트롤과 다른 코드 개체로 구문 분석하고 메시지를 전달하는 스레드가 프로그램 (주로 프로그램 실행 스레드)에 있습니다. 이 "GUI 메시징 스레드"는 프로그램의 모든 GUI 객체에 대한 모든 윈도우 핸들에 대한 참조를 알고 유지합니다. 그렇지 않으면 메시지를 전달할 수 없으며 메시지를 수신하지 않기 때문에 필수적입니다.
일반적으로 메시지 루프에 연결된 스레드 외부에서 GUI 컨트롤 인스턴스로 무엇인가하려고하면 좋지 않은 생각입니다. 이렇게하면 컨트롤에 소유 된 컨트롤 또는 하위 컨트롤이 메시지 루프에서 분리되거나 처음부터 연결되지 않을 수 있습니다. "GUI 메시지 스레드"는 더 이상 해당 컨트롤을 알지 못하며 더 이상 메시지를주고받지 않습니다. 이러한 통제는 "불량"이됩니다. 프로그램도 Windows도 컨트롤을 이동하거나, 다시 그리거나, 사라지라고 제어 할 수 없습니다. Windows가 그 시점에서 창을 "제어"할 수있는 유일한 방법은 소유하고있는 프로세스를 종료하여 전체 프로그램을 종료하는 것입니다.
GUI 컨트롤에는 GUI 메시징 스레드 외부에서 사용하도록 설계된 "Invoke"(및 비동기 사촌 "BeginInvoke")라는 특수 메서드가 있습니다. 이러한 메서드는 기본적으로 Windows GUI에서 스레드가 Invoke 호출에 지정된 대리자를 실행하게하는 Windows 메시지 루프를 통해 창에서 메시지를 자신에게 보냅니다. 그렇게함으로써, 그 코드 내에서 또는 그 결과로 생성 된 새로운 GUI 객체는 주 GUI 스레드에 알려지게됩니다.
사용자 지정 스레드는 사용자 지정 스레드에서 핸들을 만들 때 핸들을 소유 할 수 있습니다. 사실 나는 당신이 핸들의 소유자를 바꿀 수 있다고 생각하지 않습니다. 공유도 불가능합니다.
스레드가 동시에 여러 핸들을 소유 할 수 있습니다.
모든 창은 창을 만든 스레드가 소유합니다.많은 창 작업은 해당 스레드에서만 수행 될 수 있으므로 코드가 창 스레드에서 실행되도록하는 메커니즘을 갖는 것이 중요합니다.
Forms.Invoke는 이러한 메커니즘 중 하나입니다.
정확히 무엇이 문제입니까? 맞춤 스레드가 다른 스레드를 소유 할 수 있다면 창 핸들? –
@FelixK., Spot on. – ebb
관리되는 스레드는 반드시 OS 스레드에 직접 매핑되지 않으며 호스트에 따라 달라집니다. NET CLR 호스트가 SQL Server와 다르게 관리합니다. –