Yes, if you expect to log data for the duration of the application, I'd run
that logging thread the whole time. You could run it at a lower priority so
that logging doesn't interfere with packet processing, if you like, too.
In this case, there's a disconnect between how you'd like to do things using
the Win32 API and how .NET CF will support you doing it. Sometimes I lose
track of which newsgroup I'm in; sorry about that. Using C/C++, you'd have
the OS create a message queue for you and use PostTheadMessage() to send the
logging information from the reader and writer threads to the logging
thread. In .NET CF, you may need to create a managed version of this
"message queue" which is thread-safe. The collection classes have the
necessary tools for doing this. Here's a paragraph from a recent post by
Alex F. on this topic:
Yes, the collection objects (List, Queue, Hashtable etc) have a property
called SyncRoot. When you use lock to protect access to a collection, make
sure you lock this SyncRoot and not the collection object itself. Most of
the collection objects also provide static method Synchronized() that return
a wrapper of the same class which is thread-safe, i.e. you don't need locks
when accessing it. Neither method will prevent you from modifying a
collection while another thread tries to enumerate it. To handle this
situation, you will need to set a lock on the collection object itself.
You'd use a Queue for this application and create some sort of object class
which gives the logging thread the necessary information to put the right
data in the file. The logging thread would read from the head, and the
reader and writer threads would add items to the end. Since I don't think
that you need to enumerate the collection, you can probably just use the
Synchronized() static method to get a wrapper which is thread safe and use
that from all of your threads, rather than using locking.
Paul T.