Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

운영체제의 스레드 문맥 교환(Context Switch)을 유사하게 구현하는 방법

며칠 전에, 사내에서 비동기 스레드와 관련된 약식 세미나를 했는데요, 관련해서 Thread Context를 설명하면서 생각난 것이 바로 이번 글의 주제였습니다. 사실 지난번 글은 본격적으로 쓰기 전에 잠시 머물렀던 것이고. ^^

C 언어의 setjmp/longjmp 기능을 Thread Context를 이용해 유사하게 구현하는 방법
; https://www.sysnet.pe.kr/2/0/12695

이번에도 역시 그냥 재미로 봐주시면 되겠습니다. ^^ (현업에서 쓸 일이 없습니다.)




예를 들기 위해, 스레드 2개를 생성해 1초마다 스레드 ID를 출력하는 코드를 작성해 보겠습니다.

// x64 환경에서 64비트로만 실행

#include <iostream>
#include <windows.h>

volatile bool g_threadRun = true;

DWORD WINAPI threadFunc1(LPVOID lpThreadParameter)
{
    while (g_threadRun)
    {
        Sleep(1000);
        ::printf("threadFunc1: %d\n", GetCurrentThreadId());
    }

    return 0;
}

DWORD WINAPI threadFunc2(LPVOID lpThreadParameter)
{
    while (g_threadRun)
    {
        Sleep(1000);
        ::printf("threadFunc2: %d\n", GetCurrentThreadId());
    }

    return 0;
}

int main()
{
    HANDLE vCpu1 = ::CreateThread(nullptr, 0, threadFunc1, nullptr, 0, nullptr);
    HANDLE vCpu2 = ::CreateThread(nullptr, 0, threadFunc2, nullptr, 0, nullptr);

    Sleep(3000);
    
    ::SuspendThread(vCpu1);
    ::SuspendThread(vCpu2);

    ::ResumeThread(vCpu1);
    ::ResumeThread(vCpu2);

    Sleep(3000);

    g_threadRun = false;
}

보다시피 코드는 어렵지 않으며 단지 2개의 Thread 함수를 생성, 3초 후에 잠시 멈췄다가 다시 실행을 반복해 3초 후에 응용 프로그램을 종료합니다. 따라서, 대충 다음과 같은 식의 출력 결과를 볼 수 있습니다.

threadFunc1: 2844
threadFunc2: 10948
threadFunc1: 2844
threadFunc2: 10948
...

이제 한 가지 가정을 해봅니다. vCpu1 스레드가 가상 CPU1, vCpu2 스레드가 가상 CPU2라고 가정하는 것입니다. 그래서, 가상 CPU1이 처음에는 threadFunc1을, 가상 CPU2가 threadFunc2를 실행하다가 (임의로 만든) 스레드 스케줄러가 구동되면 가상 CPU1에 threadFunc2가, 가상 CPU2에 threadFunc1이 할당이 된 것을 구현하는 것입니다.

자, 그럼 SuspendThread와 ResumeThread 사이에 GetThreadContext/SetThreadContext를 이용해 2개의 스레드 Context를 통째로 바꿔보겠습니다.

volatile bool g_switched = false;

DWORD WINAPI threadFunc1(LPVOID lpThreadParameter)
{
    ::printf("threadFunc1: %d\n", GetCurrentThreadId());

    while (g_threadRun)
    {
        Sleep(1000);

        if (g_switched == true)
        {
            ::printf("[switch] threadFunc1: %d\n", GetCurrentThreadId());
        }
    }

    return 0;
}

DWORD WINAPI threadFunc2(LPVOID lpThreadParameter)
{
    ::printf("[switch] threadFunc2: %d\n", GetCurrentThreadId());

    while (g_threadRun)
    {
        Sleep(1000);

        if (g_switched == true)
        {
            ::printf("[switch] threadFunc2: %d\n", GetCurrentThreadId());
        }
    }

    return 0;
}

int main()
{
    // ...[생략]...

    Sleep(3000);
    
    ::SuspendThread(vCpu1);
    ::SuspendThread(vCpu2);

    CONTEXT ctxThread1 = { 0 };
    CONTEXT ctxThread2 = { 0 };

    ctxThread1.ContextFlags = CONTEXT_ALL;
    ctxThread2.ContextFlags = CONTEXT_ALL;

    ::GetThreadContext(vCpu1, &ctxThread1);
    ::GetThreadContext(vCpu2, &ctxThread2);

    ::SetThreadContext(vCpu1, &ctxThread1);
    ::SetThreadContext(vCpu2, &ctxThread2);

    g_switched = true;

    ::ResumeThread(vCpu1);
    ::ResumeThread(vCpu2);

    // ...[생략]...
}

실행하면 어떻게 될까요? 아쉽게도 현재는 이런 예외가 발생합니다.

Unhandled exception at 0x00007FFD3FFB5C88 (ucrtbased.dll) in ConsoleApplication1.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000003151103000).

다소 뜬금없지만 Stack overflow가 다음의 호출 스택상에서 발생합니다.

>    ucrtbased.dll!__chkstk() Line 109   Unknown Symbols loaded.
    ucrtbased.dll!write_text_ansi_nolock(const int fh, const char * const buffer, const unsigned int buffer_size) Line 381  C++ Symbols loaded.
    ucrtbased.dll!_write_nolock(int fh=0x00000001, const void * buffer=0x0000019d6b0e6a40, unsigned int buffer_size=0x00000033) Line 667    C++ Symbols loaded.
    ucrtbased.dll!_write(int fh=0x00000001, const void * buffer=0x0000019d6b0e6a40, unsigned int size=0x00000033) Line 64   C++ Symbols loaded.
    // ...[생략]...
    ConsoleApplication1.exe!printf(const char * const _Format=0x00007ff7df71bdb0, ...) Line 960 C++ Symbols loaded.
    ConsoleApplication1.exe!threadFunc1(void * lpThreadParameter=0x0000000000000000) Line 34    C++ Symbols loaded.
    kernel32.dll!BaseThreadInitThunk() Unknown Symbols loaded.
    ntdll.dll!RtlUserThreadStart() Unknown Symbols loaded.




일단 직접적인 오류 원인은 __chkstk에서의 스택 검증 코드 때문인데요, 왜 이런 오류가 발생하는지는 Visual Studio IDE 내에서 Disassembly 창을 통해 역어셈블한 코드를 보면 알 수 있습니다.

--- VCCRT\vcstartup\src\misc\amd64\chkstk.asm ----------------------------------
00007FFD328A5C50 48 83 EC 10          sub         rsp,10h  
00007FFD328A5C54 4C 89 14 24          mov         qword ptr [rsp],r10  
00007FFD328A5C58 4C 89 5C 24 08       mov         qword ptr [rsp+8],r11  
00007FFD328A5C5D 4D 33 DB             xor         r11,r11  
00007FFD328A5C60 4C 8D 54 24 18       lea         r10,[rsp+18h]  
00007FFD328A5C65 4C 2B D0             sub         r10,rax  
00007FFD328A5C68 4D 0F 42 D3          cmovb       r10,r11  
00007FFD328A5C6C 65 4C 8B 1C 25 10 00 00 00 mov         r11,qword ptr gs:[10h]  
00007FFD328A5C75 4D 3B D3             cmp         r10,r11  
00007FFD328A5C78 F2 73 17             bnd jae     cs10+11h (07FFD328A5C92h)  
00007FFD328A5C7B 66 41 81 E2 00 F0    and         r10w,0F000h  
00007FFD328A5C81 4D 8D 9B 00 F0 FF FF lea         r11,[r11-1000h]  
00007FFD328A5C88 41 C6 03 00          mov         byte ptr [r11],0  
00007FFD328A5C8C 4D 3B D3             cmp         r10,r11  
00007FFD328A5C8F F2 75 EF             bnd jne     cs10 (07FFD328A5C81h)  
00007FFD328A5C92 4C 8B 14 24          mov         r10,qword ptr [rsp]
00007FFD328A5C96 4C 8B 5C 24 08       mov         r11,qword ptr [rsp+8]  
00007FFD328A5C9B 48 83 C4 10          add         rsp,10h  
00007FFD328A5C9F F2 C3                bnd ret  

위에서 보면 gs:[10h]을 접근하는 것이 보이는데, 관련해서 다음의 글에서 정보를 얻을 수 있습니다.

What is the purpose of the _chkstk() function?
; https://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function

Win32 Thread Information Block
; https://en.wikipedia.org/wiki/Win32_Thread_Information_Block

pointer FS:[0x04]   GS:[0x08]   Win9x and NT    Stack Base / Bottom of stack (high address)
pointer FS:[0x08]   GS:[0x10]   Win9x and NT    Stack Limit / Ceiling of stack (low address)

그러니까, ucrtbased.dll!__chkstk 함수는 Stack 상황에 대한 유효성을 검사하는데, 그 과정에서 GS:[0x10], 즉 TEBStackLimit 값을 활용하고 있는 것입니다.

아울러, __chkstk 함수는 printf 호출로 발생한 것이므로 (__chkstk을 포함하지 않는) 코드만을 실행하면 위와 같은 예외는 발생하지 않습니다.




그런데, 왜 저것이 문제가 되는 걸까요? 이것은 그림으로 보면 더 쉽게 이해가 됩니다. 예를 들어, 아래는 스레드 문맥 교환을 하기 전의 상태를 나타냅니다.

thread_context_1.png

저 상태에서 스레드 문맥 교환을 하면, 상대방의 RSP 레지스터를 취하게 되므로 다음의 그림과 같이 바뀌게 됩니다.

thread_context_2.png

명확하죠? ^^ 스레드 자체가 가지고 있는 TEB(Thread Environment Block) 정보가 context switch 이후의 상황과 맞지 않아서 발생하는 것입니다.

여기서 재미있는 것은, 이번 글의 예제에서 생성한 2개의 스레드 중 두 번째의 것을 주석 처리하면,

::ResumeThread(vCpu1);
// ::ResumeThread(vCpu2); // 두 번째 스레드의 동작은 crash 발생

crash가 발생하지 않습니다. 그 이유는, __chkstk이 스택의 정합성을 stackBase와 stackLimit 범위로 결정하지 않기 때문입니다. 다시 chkstak.asm의 코드를 보면,

...[생략]...
00007FFD328A5C68 4D 0F 42 D3          cmovb       r10,r11  
00007FFD328A5C6C 65 4C 8B 1C 25 10 00 00 00 mov         r11,qword ptr gs:[10h]  
00007FFD328A5C75 4D 3B D3             cmp         r10,r11
00007FFD328A5C78 F2 73 17             bnd jae     cs10+11h (07FFD328A5C92h)
00007FFD328A5C7B 66 41 81 E2 00 F0    and         r10w,0F000h  
00007FFD328A5C81 4D 8D 9B 00 F0 FF FF lea         r11,[r11-1000h]  
00007FFD328A5C88 41 C6 03 00          mov         byte ptr [r11],0  
00007FFD328A5C8C 4D 3B D3             cmp         r10,r11  
00007FFD328A5C8F F2 75 EF             bnd jne     cs10 (07FFD328A5C81h)  
00007FFD328A5C92 4C 8B 14 24          mov         r10,qword ptr [rsp]  
00007FFD328A5C96 4C 8B 5C 24 08       mov         r11,qword ptr [rsp+8]  
00007FFD328A5C9B 48 83 C4 10          add         rsp,10h  
00007FFD328A5C9F F2 C3                bnd ret  

r11에 담긴 stackLimit와 r10에 담긴 RSP 값을 비교해 RSP 값이 크거나 같으면(CF=0) 0x00007FFD328A5C92 주소로 곧바로 점프해 그 사이의 (crash를 유발하는) 코드를 생략합니다. 따라서 위의 두 번재 그림을 보면 둘 중 하나의 스레드는 RSP 값이 stackLimit보다 크게 되고 그 스레드에 한해서는 __chkstk의 crash 코드를 피하게 되는 것입니다.

자, 그럼 crash가 하필 Access Violation도 아니고 왜 StackOverflow인지 궁금한데요, 이것은 위의 jae 점프 문이 동작하지 않았을 때 실행되는 중간 코드를 보면 알 수 있습니다.

00007FFD2D9C5C81  lea         r11,[r11-1000h]  
00007FFD2D9C5C88  mov         byte ptr [r11],0  
00007FFD2D9C5C8C  cmp         r10,r11  
00007FFD2D9C5C8F  bnd jne     cs10 (07FFD2D9C5C81h)

위의 코드는 (r10에 담긴) RSP 값을 (앞선 코드에서 실행한 "and r10w,0F000h"로 인해) 4KB 정렬된 값을 stackLimit와 비교해 같을 때까지 계속해서 stackLimit 값을 (아래로) 늘리기 때문입니다. 즉, stackLimit에서 계속 4KB씩 스택이 자라면서 결국 상한(기본값 - 32비트 1MB / 64비트 4MB)을 넘게 돼 stack-overflow 예외가 발생하는 것입니다.




자, 이렇게 해서 원인 파악을 제대로 했으니 이제 문제를 수정할 차례입니다. 당연히, 우리가 해야 할 것은 해당 스레드의 stackBase와 stackLimit 값을 서로의 값으로 바꾸면 되는데, 이것은 다음의 Q&A에서 공개한 코드를 통해 해결할 수 있습니다.

Getting the TIB/TEB of a Thread by it's Thread Handle (2015)
; https://stackoverflow.com/questions/32297431/getting-the-tib-teb-of-a-thread-by-its-thread-handle-2015

따라서 대충 이런 식으로 Context Switch와 함께 추가하면,

// ...[생략]...

int main()
{   
    // ...[생략]...

    SwitchStackInfoInTEB(vCpu1, vCpu2);

    ::SetThreadContext(vCpu2, &amp;ctxThread1);
    ::SetThreadContext(vCpu1, &amp;ctxThread2);
    // ...[생략]...
}

void SwitchStackInfoInTEB(HANDLE vCpu1, HANDLE vCpu2)
{
    DWORD64 stackBase1, stackLimit1;
    DWORD64 stackBase2, stackLimit2;
    void* teb1 = GetThreadStackTopAddress(GetCurrentProcess(), vCpu1, &stackBase1, &stackLimit1);
    void* teb2 = GetThreadStackTopAddress(GetCurrentProcess(), vCpu2, &stackBase2, &stackLimit2);

    *(DWORD64*)((BYTE*)teb1 + 0x08) = stackBase2;
    *(DWORD64*)((BYTE*)teb1 + 0x10) = stackLimit2;

    *(DWORD64*)((BYTE*)teb2 + 0x08) = stackBase1;
    *(DWORD64*)((BYTE*)teb2 + 0x10) = stackLimit1;
}

// https://stackoverflow.com/questions/32297431/getting-the-tib-teb-of-a-thread-by-its-thread-handle-2015
void* GetThreadStackTopAddress(HANDLE hProcess, HANDLE hThread, /* OUT */ DWORD64* pStackBase, /* OUT */ DWORD64* pStackLimit)
{
    HMODULE module = GetModuleHandle(L"ntdll.dll");

    if (module == nullptr)
    {
        return nullptr;
    }

    NTSTATUS(__stdcall * NtQueryInformationThread)(HANDLE ThreadHandle, THREADINFOCLASS ThreadInformationClass, PVOID ThreadInformation, ULONG ThreadInformationLength, PULONG ReturnLength);
    NtQueryInformationThread = reinterpret_cast<decltype(NtQueryInformationThread)>(GetProcAddress(module, "NtQueryInformationThread"));

    if (NtQueryInformationThread)
    {
        NT_TIB tib = { 0 };
        THREAD_BASIC_INFORMATION tbi = { 0 };

        NTSTATUS status = NtQueryInformationThread(hThread, ThreadBasicInformation, &tbi, sizeof(tbi), nullptr);
        if (status >= 0)
        {
            ReadProcessMemory(hProcess, tbi.TebBaseAddress, &tib, sizeof(tbi), nullptr);

            *pStackBase = (DWORD64)tib.StackBase;
            *pStackLimit = (DWORD64)tib.StackLimit;

            return tbi.TebBaseAddress;
        }
    }

    return nullptr;
}

정상적인 실행 결과를 얻을 수 있습니다. ^^

threadFunc1: 396
threadFunc2: 13496
[switch] threadFunc1: 13496
[switch] threadFunc2: 396
...[생략]...

결국 OS의 Context Switch는 CPU 레지스터의 문맥 교환뿐 아니라 TEB 영역의 스택 정보까지 보정하는 역할을 하고 있는 것입니다. 이런 면에서 생각했을 때 엄밀히 위의 코드는 안정적인 실행을 보장하지 않습니다. 왜냐하면 TEB의 또 어떤 값이 업데이트 되어야 하는지에 대한 정보가 없어 자칫 (__chkstk처럼) 그 영역을 접근하는 데이터가 있다면 정합성이 맞지 않아 마찬가지로 crash 등의 문제가 발생할 수 있기 때문입니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




마지막으로, 한 가지 더 실험을 해볼까요? ^^

이번 글의 예제처럼, 스레드 1과 스레드 2가 실행하는 함수의 구조가 동일하고 문맥 변경을 하는 순간의 위치가 같다면 (TEB 정보를 바꾸지 않고) RSP 레지스터를 보존하는 식으로 수행해도 다행히 실행 중 crash 문제는 벗어납니다.

::GetThreadContext(vCpu1, &ctxThread1);
::GetThreadContext(vCpu2, &ctxThread2);

DWORD64 rsp1 = ctxThread1.Rsp;
ctxThread1.Rsp = ctxThread2.Rsp;
ctxThread2.Rsp = rsp1;

// SwitchStackInfoInTEB(vCpu1, vCpu2);

::SetThreadContext(vCpu2, &ctxThread1);
::SetThreadContext(vCpu1, &ctxThread2);

재미있는 것은, 저렇게 했을 때의 출력 결과를 보면 마치 SetThreadContext 호출을 하지 않은 것처럼 동작을 합니다.

threadFunc1: 22344
threadFunc2: 1872
[switch] threadFunc1: 22344
[switch] threadFunc2: 1872
// ...[생략]...

보는 바와 같이 threadFunc1과 2를 실행하는 Thread ID가 동일합니다. 이런 결과가 나온 것은, 문맥 변경 시 2개의 스레드 모두 Kernel로 진입하는 API를 호출했기 때문입니다. 예제에서처럼 Sleep의 경우 NtDelayExecution 함수에서 syscall을 이용해 커널로 진입하게 되는데,

--- NtDelayExecution
...[생략]...
00007FFDCBFED488  nop         dword ptr [rax+rax]  
00007FFDCBFED490  mov         r10,rcx  
00007FFDCBFED493  mov         eax,34h  
00007FFDCBFED498  test        byte ptr [7FFE0308h],1  
00007FFDCBFED4A0  jne         NtDelayExecution+15h (07FFDCBFED4A5h)  
00007FFDCBFED4A2  syscall  
00007FFDCBFED4A4  ret  

syscall 명령어는 사용자 모드의 RIP를 커널 진입/탈출 시 보존/복원하기 때문에,

SYSCALL — Fast System Call
; https://www.felixcloutier.com/x86/syscall

우리가 수행했던 SetThreadContext로 인한 RIP 변경은 커널에서의 Sleep 동작이 끝나 반환되면서 무효화됩니다. 또한 syscall 명령어 자체는 RSP 레지스터에 대한 보존/복원은 하지 않지만, 대신 윈도우 운영체제 측의 KiSystemCall64에서 이것을 담당합니다.

// https://github.com/DarthTon/HyperBone/blob/master/src/Hooks/Syscall.asm
// https://stackoverflow.com/questions/65367333/breakpoint-setting-in-ntkisystemcall64-not-working
0: kd> u fffff802`3681e6c0
nt!KiSystemCall64:
fffff802`3681e6c0 0f01f8          swapgs
fffff802`3681e6c3 654889242510000000 mov   qword ptr gs:[10h],rsp
fffff802`3681e6cc 65488b2425a8010000 mov   rsp,qword ptr gs:[1A8h]
fffff802`3681e6d5 6a2b            push    2Bh
fffff802`3681e6d7 65ff342510000000 push    qword ptr gs:[10h]
fffff802`3681e6df 4153            push    r11
fffff802`3681e6e1 6a33            push    33h
fffff802`3681e6e3 51              push    rcx

위의 코드를 보면, 값의 저장을 gs:[10h]에 하고 있지만 이때의 gs는 TEB 영역을 가리키는 것이 아니고 그 이전의 swapgs 때문에 kernel 영역의 MSR이 가리키는 주솟값으로 바뀌게 됩니다. 즉 별도로 커널 영역에 사용자 모드의 RSP 값을 보관한 후, 커널에서의 작업을 마치고 나서 다시 사용자 모드의 RSP 값을 swapgs/gs:[10h]로 복원을 해줍니다.

결국 Kernel로 진입한 동안에 스레드 문맥을 (RSP를 포함해) 교환하면 해당 함수 호출이 완료된 후에는 이전에 보관해 두었던 RSP/RIP가 복원되기 때문에 스레드 문맥 교환이 발생하지 않은 것처럼 동작하게 되는 것입니다.

이에 대한 검증은, 스레드 함수에 아래와 같이 커널 진입을 하지 않는 코드로 확인할 수 있습니다.

DWORD WINAPI threadFunc1(LPVOID lpThreadParameter)
{
    ::printf("threadFunc1: %d\n", GetCurrentThreadId());

    while (g_switched == false) // 사용자 모드에서 문맥 교환이 될 때까지 무한 루프
    {
        static int i = 0;
        i ++;
    }

    while (g_threadRun)
    {
        Sleep(1000);

        if (g_switched == true)
        {
            ::printf("[switch] threadFunc1: %d\n", GetCurrentThreadId());
        }
    }

    return 0;
}

DWORD WINAPI threadFunc2(LPVOID lpThreadParameter)
{
    ::printf("threadFunc2: %d\n", GetCurrentThreadId());

    while (g_switched == false) // 사용자 모드에서 문맥 교환이 될 때까지 무한 루프
    {
        static int i = 0;
        i ++;
    }

    while (g_threadRun)
    {
        Sleep(1000);

        if (g_switched == true)
        {
            ::printf("[switch] threadFunc2: %d\n", GetCurrentThreadId());
        }
    }

    return 0;
}

그럼, while 루프 동안에 Context Switch가 발생하게 되고, 출력 결과를 보면 스레드 ID가 바뀌어 있습니다.

threadFunc1: 1904
threadFunc2: 3164
[switch] threadFunc1: 3164
[switch] threadFunc2: 1904
...[생략]...
F:\ConsoleApp1\x64\Debug\ConsoleApp1.exe (process 19572) exited with code -1073740791.

그렇긴 해도, 보는 바와 같이 스레드의 실행 자체는 되었지만 exit code가 0xC0000409(-1073740791)로 비정상 종료를 합니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]



donaricano-btn



[최초 등록일: ]
[최종 수정일: 7/6/2021

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 쓴 사람
 




1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12815정성태8/30/2021196개발 환경 구성: 602. WSL 2 - docker-desktop-data, docker-desktop (%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx) 파일을 다른 디렉터리로 옮기는 방법
12814정성태8/30/2021259.NET Framework: 1110. C# 10 - (12) 인터페이스 내에 정적 추상 메서드 정의 가능파일 다운로드1
12813정성태8/29/2021248.NET Framework: 1109. C# 10 - (11) Lambda 개선파일 다운로드1
12812정성태8/28/2021234.NET Framework: 1108. C# 10 - (10) 개선된 #line 지시자
12811정성태8/27/2021196Linux: 44. 윈도우 개발자를 위한 리눅스 fork 동작 방식 설명 (파이썬 코드)
12810정성태8/27/2021131.NET Framework: 1107. .NET Core/5+에서 동적 컴파일한 C# 코드를 (Breakpoint도 활용하며) 디버깅하는 방법 - #line 지시자파일 다운로드1
12809정성태8/26/2021226.NET Framework: 1106. .NET Core/5+에서 C# 코드를 동적으로 컴파일/사용하는 방법파일 다운로드1
12808정성태8/25/2021123오류 유형: 758. go: ...: missing go.sum entry; to add it: go mod download ...
12807정성태8/25/2021219.NET Framework: 1105. C# 10 - (9) 비동기 메서드가 사용할 AsyncMethodBuilder 선택 가능파일 다운로드1
12806정성태8/24/2021169개발 환경 구성: 601. PyCharm - 다중 프로세스 디버깅 방법
12805정성태8/24/2021155.NET Framework: 1104. C# 10 - (8) 분해 구문에서 기존 변수의 재사용 가능파일 다운로드1
12804정성태8/24/2021162.NET Framework: 1103. C# 10 - (7)
12803정성태8/23/2021114개발 환경 구성: 600. pip cache 디렉터리 옮기는 방법
12802정성태8/23/2021218.NET Framework: 1102. .NET Conf Mini 21.08 - WinUI 3 따라해 보기
12801정성태8/23/2021129.NET Framework: 1101. C# 10 - (6) record class 타입의 ToString 메서드를 sealed 처리 허용파일 다운로드1
12800정성태8/22/2021130개발 환경 구성: 599. PyCharm - (반대로) 원격 프로세스가 PyCharm에 디버그 연결하는 방법
12799정성태8/22/2021216.NET Framework: 1100. C# 10 - (5) 속성 패턴의 개선파일 다운로드1
12798정성태8/21/2021309개발 환경 구성: 598. PyCharm - 원격 프로세스를 디버그하는 방법
12797정성태8/21/2021116Windows: 197. TCP의 MSS(Maximum Segment Size) 크기는 고정된 것일까요?
12796정성태8/21/2021211.NET Framework: 1099. C# 10 - (4) 상수 문자열에 포맷 식 사용 가능파일 다운로드1
12795정성태8/20/2021273.NET Framework: 1098. .NET 6에 포함된 신규 BCL API - 스레드 관련
12794정성태8/20/2021599스크립트: 23. 파이썬 - WSGI를 만족하는 최소한의 구현 코드 및 PyCharm에서의 디버깅 방법 [1]
12793정성태8/20/2021673.NET Framework: 1097. C# 10 - (3) 개선된 변수 초기화 판정파일 다운로드1
12792정성태8/19/2021207.NET Framework: 1096. C# 10 - (2) 전역 네임스페이스 선언파일 다운로드1
12791정성태8/19/2021156.NET Framework: 1095. C# COM 개체를 C++에서 사용하는 예제 [3]파일 다운로드1
12790정성태8/18/2021277.NET Framework: 1094. C# 10 - (1) 구조체를 생성하는 record struct파일 다운로드1
1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...