Network Manager / Threads

[Andrew J Berkley <berkley@wam.umd.edu>]

On Tue, 2 Sep 1997, M.Stekelenburg <m.stekelenburg@student.utwente.nl> wrote:
> I'll write an extra filter to go from the messages to a normal file
> stream. This way i can remove the extra read code in the jpeg filter and,
> if makes adding image filters easier because a lot of those libraries
> expect an file to read from. 

If you could do it without using a thread it would be even better (I was
envisioning only a Network thread, a Display thread, a DNS thread, and
perhaps a Java thread, etc.), but I suppose we can eventually move to our
own jpg or whatever code that handles data-push stuff (it looks as if we
can easily move the GIF code to being push oriented, as it is already
written as a pseudo-state machine).

Also, the FilterStack uses a thread!  Why?  The NetworkManager gives it
time via the receiveMessage() call -- the whole idea is to use that
timeslice to do your processing.  As far as I can tell the FilterStack
thread wakes up when receiveMessage() is called, and then pushes the data
to the filters.  That should just happen in receiveMessage, unless you
think that a single message push would cause an absurdly long block time.

The Network thread is to be used for all data related events.  The Display
thread is for running gtk_main().  Eventually I will add another thread
that provides timer support, etc (for JavaScript or whatever), or maybe
I'll use the Network thread.

When the network thread blocks (maybe we pass a horribly complex 8192 byte
block to some parser), all that happens is that no other data gets pushed
through the stacks.  The display still can be scrolled, and new
connections can be created (though no data will flow until the block
finishes).  If you think processing something will take on the order of
seconds per block, then maybe it is worth it to create a new thread, but I
really don't think any normal filter operations are going to take that
long.

Andrew