Re: Dupping message data

[dave@computone.com (David Johnson) writes:]

>Normally packets are sent up in a STREAMS environment asynchronously to the
>modules above. They process them and send them to the STREAM head which
>holds them for the user. However, in the server model, how can the TCP
>module keep a pending receive in the Ethernet server and still service other
>write requests from above?

Well, the simplest way would be to launch another thread within the
TCP process (see tfork(), more comments below), have him forever post
reads, then requeue the responses to the TCP queue. Something like:

        User program Ethernet (read)
             | |
             |<----------+ |
             V ^ V
        +----+-----------+---+-+
        | thread1 thread2|
        | TCP server |
        +----+-----------------+
             |
             V
        Ethernet (write)

So thread1 would do all the "real" work, with thread2 just gather
packets and mixing them onto the single queue of thread1. thread1
reads requests and ether packets, and generates responses upwards
as well as transmitted packets downwards.

If the ethernet driver tended to block transmit requests, you might
even use a third thread to do the writes to ethernet. This would allow
thread1 to continue running while writes were queued up and blocked.

Now, some comments concerning threading. tfork() exists, and works. I
use it a little, but am considering adding a second parameter. The
existing parameter specifies where the thread should start running
at (there are good reasons to do this instead of UNIX sementics for
fork()); I think I should add a second parameter which is passed as
the single argument on the stack to the new thread.

I also know that the microkernel will need to offer some sort of
semaphore facility to help threads coordinate, but haven't added it
yet. I have a pretty good idea of what a multi-threaded multiprocessor
kernel environment is like (I did UNIX kernel work at Sequent), but
such an environment is very difficult, and I've been holding off
implementing something until I felt I better understood a multi-
threaded server process environment. Discussions like this help!

                                        Andy
Received on Wed Oct 13 08:30:57 1993