Re: Thread implementations...
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Wed, 24 Jun 1998 11:10:54 +1000
Dean Gaudet writes:
> On Wed, 24 Jun 1998, Richard Gooch wrote:
>
> > Sorry, I still don't see the difference between your completion ports
> > and event queues. In both cases, as far as I can tell, when I/O
> > completes a "message" is sent to some place. The application can then
> > pick off these events. Part of the message includes the FD which had
> > the completed I/O.
>
> completion port:
>
> 1. write(FD, buf, 16384) ==> returns some code indicating I/O in progress
> 2. some time later all 16384 bytes are written (or error occurs)
> 3. app gets a completion event from the port
>
> select/poll:
>
> 1. write(FD, buf, 16384) ==> 4096
> 2. write(FD, buf+4096, 12288) ==> EWOULDBLOCK
> 3. put FD into poll/select sets
> 4. some time later poll/select indicates ready for write
> 5. go back to 1, try to write more from buf
>
> readiness queue:
> 1. write(FD, buf, 16384) ==> 4096
> 2. write(FD, buf+4096, 12288) ==> EWOULDBLOCK
> 3. at this point the kernel notes that you've been told EWOULDBLOCK,
> and when it's ready for write on FD it will have to send you a
> readiness event
> 4. some time later get readiness event from event queue
> 5. go back to 1, try to write more from buf
>
> In the completion port case the kernel has done all the work of
> "completing" the request. In the other two cases the kernel only does
> the work of saying "I'm ready for another write/read", no indication of
> how much progress you'll make.
OK, I see the difference now. Given your definition, I think readiness
queues are a better scheme than completion ports. Also, readiness
queues would be easier to implement: the same place where you wake up
processes waiting in poll(2) is where you shove the FD down a ready
pipe.
Once my fastpoll patch makes it into the kernel, adding completion
ports (if required:-) would be easier.
> Notice the similarity between select/poll and readiness queue ... the
> only difference is how the kernel is asked to tell you of readiness.
> For the readiness queue we've presumably done an ioctl() on FD earlier
> on telling the kernel to do this special processing on EWOULDBLOCK.
Yep, an ioctl(2) seems like a reasonable way to do this. There are of
course issues with multiple processes and such which can make this
tricky.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu