NET-SNMP 오프소스에서 Asynchronous API를 사용하여 새로운 MIB 추가할때 구현 방법은?

안녕하세요.

NET-SNMP소스에서 DOT3 EPON MIB 및 DOT3 OAM MIB를 구현하려고 하고 있습니다.

관련해서 문제에 봉착 했는데요.

상기 MIB를 얻는 값들을 칩셋 업체가 제공하는 API에서 Asynchronous API로 제공 하고 있습니다.

즉 Callback 등록을 하고 일정시간 후에 Callback 함수들이 호출되어 MIB 값들이 반환되는 형태 입니다.

이럴 경우 제 생각에 휴대폰 단말의 Task 개념으로 접근한다면 현재의 MIB을 요청한 Task가 MIB 값을 요청하고

(Callback 등록요청) Block 되고 값이 나중에 리턴 되면(해당 Callback 호출 되면)

SNMP Response Message을 리턴하기 위해

Block된 Task가 깨어나서 처리해야 할 것 같은데? 어떻게 구현 해야 할지 몰라서요.

이렇게 값이 바로 호출해서 구하기 힘든 경우(not Synchronous API)에 어떻게 해야 하나요?

하나의 Task을 생성하고, Task간 context Switch 같은 것을 컨트롤 할 수 있는 함수가 있으면 가능할 것 같으네?

제가 휴대폰 단말쪽만 해서리 이쪽 리눅스에 경험이 일천해서 감이 잘 안나오네요.

관련해서 아시는 분 도움 부탁합니다. 리눅스에서 Task=process가 형태로 운영되고 하나의 Process내에서 여러 Thread가 돌 수 있는 구조로 되어 있으나 현재는 Process당 하나의 Thread로 운연된다. 이거 맞는 말인가요?

저는 휴대폰 경험(REX)을 바탕으로 으로 다음과 같이 고민하고 있는데 바른 방향인지 모르겠군요

현재의 MIB을 요청한 Thread는 Asynchronous API를 호출하여 Callback을 동록하고 현재의 Task는 Block 되고,

Asynchronous API(Kernel) 쪽에서 이 Thread를 깨워서 Callback을 호출한다. 이건 순전히 휴대폰 단말의 REX 관점에서 생각해 본거고 관련 TASK 구조가 이러지 않은 상태애서 어불성설 같고.

프로그램 초기에 Callback을 등록하고 계속 관련 값을 유지하게 해 놓고 SNMP Get Request가 오면 유지 한 값을 통해 SNMP Response를 구현해야 할까요? 이러면 불필요하게 API호출이 잦을 것 같아 안 좋을 것 같은데....

정리하자면, Net-SMMP기반 소스에서 Asynchronous API로 통한 MIB 접근 구현 방법은?

혹은 Net-SNMP 소스의 Task 혹은 Thread 관련 구조에 대해 설명?

관련 경험 있으신분 조언 부탁합니다.