안녕하세요 닷넷데브 여러분
전 현재 예전 VC6.0 으로 만들어진 프로그램의 유지 보수 및 C# 포팅 작업 업무를 맡고 있습니다.
업무를 하면서 문득 이런 궁금함이 생겨서 글을 올립니다.
기존 프로젝트에서는 GDI+ 및 그것을 출력 및 담당하는 쓰레드를 DLL 내부에서 처리하도록 되어있고 (DLL은 CLR 이 아닌 NATIVE? 입니다. extern “C” 이런식으로 API 호출식으로 되어있지요)
쓰레드 종료는 종료 함수를 호출하고 쓰레드가 종료나 이벤트 등을 처리하면 SendMessage 를 보내어 기존 mfc 로 이루어진 프로그램에서 처리하도록 되어있습니다.
DLL 이 내부API 등을 가지고 쓰레드를 돌리는게 바람직한 일일까요?
많은 답변 부탁 드립니다. 감사합니다.
네. 저는 그렇게 하고 있습니다.
SendMessage보다는 Delegate를 이용한 이벤트로 콜백해주는 방법으로요.
어떤 것이 우려 되시나요? 자세한 답변을 드리기위해 정보가 조금 더 필요합니다.
내용을 이해하기 어려워 제목에 대한 답변을 하자면 DLL 내에서 워커쓰레드, UI쓰레드 돌려도 아무 문제 없고 필요하면 돌려야죠
질문의 요지는 dll에서 쓰래드를 만들어서 돌려도 되는것인가?
맞나요?
맞다고 생각하고 답변을 달자면 아무 문제 없습니다.
다만 쓰래드에서 메인 프로그램으로 메시지를 보내는건 저 개인적으로는 싫어하는 방법이긴 합니다.
디버깅이 좀 불편해서요.
답변감사합니다. MFC DLL 인데 그럼 그 함수를 Delegate 를 이용한다는 말씀이신가요?
답변 감사합니다. ^^
구체적이지는 않지만 예전에 dll 안에서 쓰레드 사용은 권장되지 않는다는 이야기를 들은 적이 있습니다. 현재 vc6.0 mfc 으로 구성되어 있는 dll 안의 쓰레드를 보면서 그 생각이 나서 질문을 올려보았습니다.
네 질문의 요지는 맞습니다. 메세지 사용은 내부 쓰레드에서 로직처리 및 종료 등에 대해서 알려주기 위해서 사용되고 있습니다. 디버깅은 확실히 불편하더군요 ^^;;;
아네… 그렇군요. 제 경험으로는 dll 라이브러리를 구현할 때 스레드를 안 쓸 이유는 없습니다. 우리는 이미 멀티코어 CPU를 대부분 가지고 있기 때문인데요
다만 GDI+가 멀티 스레드를 고려하지 않기 때문에 리소스를 다른 스레드와 공유한다면 경합 상황은 고려하셔야 합니다.
답변 감사합니다. 현재 구성되어 있는 로직은 오직 싱글 쓰레드만을 고려되어 만들어져 있습니다. dll 내부의 api 의 용도는 dll 내부에서 gdi+ 객체들을 생성시켜서 그것을 쓰레드로 돌리는 것만을 고려되어 있습니다.
MFC DLL도 C#으로 포딩하시는게 아닌가보군요…
MFC DLL을 수정 가능하시면 아래방법도 있고.
.NET Framework: 620. C#에서 C/C++ 함수로 콜백 함수를 전달하는 예제 코드 (sysnet.pe.kr)
안된다면 기존 방법대로 SendMessage로 보내셔도 될듯합니다.