We have custom io-pkt driver that interfaces with a proprietary network interface.

Network interface is managed by a QNX resource manager, so rather then interacting with the hardware directly, our io-
pkt driver must interface with the resource manager.  This is a low-bandwidth connection, so throughput is not an issue.


Our current design spawns a thread (using pthread_create) in the io-pkt attach callback.  This thread read-blocks on the
 resource manager and when packets arrive, places them in a in-memory queue.  

In the process_interrupt callback, we check this queue for packets and push them into the io-pkt stack.

Things work well most of the time, but sometimes the system locks up.   System time appears to stop advancing, network 
calls hang and we lose serial shell connectivity.

I suspect we are violating some rules in the process_interrupt callback and blocking/corrupting the system timer.

We use standard pthread_mutex calls to protect access to the in-memory queue between the rx thread and the process 
interrupt callback. 

Should we be usings the NW_SIGLOCK calls instead?   
Is the process_interrupt() invoked in normal context or is it an interrupt or signal handler?  What are the restrictions
 on method usage in this context?

Thanks,
Dan Giorgis