[ros-kernel] Re: IOCP and fibers - not strictly related to ROS

[Phillip S. <ps...@cf...>]

At 02:20 AM 9/25/2001 +0100, you wrote:
>Fibers are just a stack and register context that you can switch out on
>demand.  They are very lightweight self-scheduled threads.  They therefore

I thought that on NT they were implemented using real threads, and just 
play games with the scheduler.  I guess I got this idea from seeing a 
function called ConvertThreadToFiber() or something.

>have ideal properties for sitting with IOCP.  The OnRecv and OnSend
>functions require you to keep track of the current state of a connection,
>and make only very light use of the stack.  IMO a stack is a pretty
>reasonable place to keep all of this data - having to store it yourself in a
>connection state structure or class is a pain.  Stacks were designed to make

I don't see how it is a pain.  The difference is having an OOD vs. a 
procedural programming model.  I prefer the OOP approach, but the 
difference at the machine level is that you keep a bit of state information 
in an object on the heap instead of on the stack.  Of course, having the 
stack for this means you have to reserve one, and even if you only use say, 
an 8kb stack, that's still a fixed 8kb for each connection, instead of 
maybe a dozen bytes on the heap.  For short lived connections, this may be 
a decent way to do it, but if you have connections that could live for a 
good duration, you could easily end up with many 8kb stacks laying around 
that aren't being used.

>your coding life easier, IOCP basically mean that you can't use them
>anywhere near as easily as intended.  Keeping the current execution location
>also saves you from storing the current state in a variable, and having to
>choose the next bit of code to execute based on that.  It's not entirely a

So instead of having state information in an object on the heap, you have 
the saved instruction pointer and variables on the stack.  Six in one hand, 
half dozen in the other.

>bad way of doing it, but consider an SMTP conversation (outgoing):
>
>         connect
>         read response
>         send HELO
>         read response
>         send MAIL
>         read response
>         send RCPT
>         ...
>
>This is basically a linear process.  Breaking the code down into little
>chunks doesn't make a huge amount of sense.  With my method, the code path

I can see your point, and not having to change existing code is a powerful 
argument, however for new code, I'd prefer to store a function pointer to 
the function for handling the next expected state, and each function is an 
easy to understand self contained piece, rather than a large block of code 
that does send/recv over and over.  I think that way the code is more 
readable.

>above would be virtually unchanged, all you do is fiddle with `read
>response' and `send' to work as listed below and you get IOCP without the
>extra coding hassle.  The other important driving factor behind this is I
>have a fair bit of legacy code that I want to convert to use IOCP.  If I
>only have to change a few functions, then I'm much happier than if I have to
>rework the whole thing!  The main other point is that my method, although it
>seems a bit of a fiddle at first instance, actually adds no more weight than
>keeping track of all this yourself.  It's just that the data for the
>connection is stored on the stack, not in a class.
True... so for ease of porting, this is a clear win, but for readability, I 
prefer an OOP approach.


>Just on the subject of IOCP they do seem to be a total hack (`set the low
>bit of the event handle in the overlapped structure to 1 to prevent IOCP

Huh?

>notification' is my favourite bit).  What is it that means that threads have
>so much weight in NT anyway?

Each thread has a 12kb kernel mode stack, as well as several other 
structures that the kernel has to keep track of, adding to the memory 
footprint.  Then the user mode stack gets added in.

>Nice FTP server by the way!  I managed to get the source code out of the
>.bz2 file you sent, but not the support libraries - I would definitely be
>interested in seeing the whole thing!

Thanks.

>Thanks,
>
>Mark

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================