아직도 윈폼을 붙잡고있어야 하는 안타까운 처지라면,

최초진입점으로 아래와 비슷한 코드를 십수년째 건들지 않고있을것이다.



나는 버르장머리 없게도 저 몇줄짜리 구습을 가만 두는 꼴을 볼수가 없다.


이번에도 저기부터 내키는대로 건들여보다 또 당했는데,



위 코드는 별문제없이 돌수있어보이나 await 시점에서 무한대기를 발생시킨다.

표현을 풀어보면 아래와같은 처리절차를 가지는데,



컨트롤이 생성되고, 애플리케이션의 메인컨트롤로 등록되지 않은 어중간한 시점에 비동기 대기가 발생하면 그렇게된다.

만일 비동기함수를 Form등의 아무컨트롤도 생성하지 않았거나, Run이후의 UI이벤트에서 호출한다면 문제없이 처리된다.



근데 또 마냥 안되는건 또 아니고 호출하는 모든 비동기함수뒤에 ConfigureAwait(false)를 붙여 같은 쓰레드로 돌아오게 하면 작동한다.



어찌어찌 최상단만 건드려서 해결할수도 있긴 하다.


엥 근데 애초에 STAThread인데 await했다고 왜 쓰레드가 쪼개지나???



까보니 애초에 STAThread 부터 아니었다... 윈폼에서는 최상위문을 쓸수없을뿐더러, Main함수가 async가 되는것조차 안된다는 사실을 나만 몰랐다.


비동기를 단일쓰레드에서 처리되게 하는건 언어단이 아니라 윈폼단에서 구현되는것이기 때문에 [STAThread]를 무시하는듯 하다. 무시하지말고 그냥 에러내면 안되나...


맘에 안드는 요점들은 결국 위와같이 당연히 잘못됬거나 사전에 숙지하여 주의해 건들여야할 사항들이, 문법이나 분석기상에서 아무진단도 안되는채로 런타임을 가야 깨박살이난다는것이다. 게다가 뭔가 잘못된 부분이 있어도 구체적인 에러없이 어중간하게 굴러는 가기때문에 본질적인 문제를 찾아내기 쉽지가 않으니, 되는대로 만들때는 별문제없었을지 몰라도 언제든지 추적되지않는 지뢰매설을 하기가 너무 쉬우니 리팩토링을 꺼리게 만들 지경이다.