[MUD-Dev] Re: lurker emerges

[Vadim Tkachenko]

T. Alexander Popiel wrote:
> 
> In message:  <35CE83C9.62363952 at freehold.crocodile.org>
>              Vadim Tkachenko <vt at freehold.crocodile.org> writes:
> >
> Hmm.  Okay, definitions are always good. :-)  They promote
> communication, as opposed to vociferous noise.

:-)

> My definitions of blocking and non-blocking I/O are as follows:

Preserved for clarity
 
> Blocking I/O: you make a library/system call requesting an I/O
> operation of a given size.  The call does not return until the
> entire operation completes for the entire size requested,
> regardless of delays incurred.  Under some implementations,
> external (and only external) sources may interrupt the call.
> Under no circumstances is your program able to do other work
> while waiting for the I/O to complete.
> 
> Non-blocking I/O: you make a library/system call requesting
> an I/O operation of a given size.  The call always returns
> 'immediately' (after minimal processing of the request,
> responding with whatever data is already on hand), with an
> indication of how much I/O was actually performed.  In some
> implementations (UNIX sockets), no further processing is done
> without additional request.  In other implementations (Amiga,
> apparently, and some of the old mainframes), when the remainder
> of the requested I/O is completed, the calling program is
> informed.  In both cases, a _separate_ library/system call is
> available to wait until more I/O is possible or I/O completes
> (depending on flavor).

Okay, now I see that I meant the same definitions, although have a
different viewpoint.

For last 2 years I'm thinking in Java, before that I'd been thinking in
C++ for 6 years, 2 of which were preemptive and multithreaded, before
that, it was Windows.

Now, I agree that UNIX may not (I'm not really strong in C++ in UNIX)
and Java does not have asynchronous I/O as you describe it. However, I
was doing the stuff mostly top-to-the-bottom and don't really see a
problem here. Let me draft it (I guess, it's pretty obvious):

ACT is the Asynchronous Completion Token (Design patterns...), has
read_count field and a semaphore.

ACT	asyncread( buffer, how_much_do_I_want, boolean all_async );

OK, so what I have is some read performed at once (no sense in async
read if I know the absolute minimum I want), and then I know how much
did I read - the ACT has it. Then, I can go out and do my stuff, and
when I'm ready I may go out and wait for the completion semaphore (let
me emphasise, _event_ semaphore).

So, on the API level - what's the difference between the _library_ call
and the simple piece of code I'm talking about? Agreed, the former may
be _much_ more effective, but if you're going to production, you need
the _scalable_ solution anyway, and if it really bothers you, go to the
platform which does have the stuff you mentioned and make it native, in
Java case.

> The most important distinction in my mind is the ability (or
> lack thereof) to separate the request and the wait for request
> completion.

Nah, the Asynchronous Completion Token is a solution in this case.

For those who still remember what is a Jukebox: guys, I'm terribly sorry
- it's in the transition from 2.0 to 3.0 right now and I'm really
ashamed to give it away as it is - it's patchy and messy, but for those
interested - I can send you the complete CVS repository today. A while
ago, the copyright issues were holding me, but not any more.

Reading the MUD-Dev too much, remember - there was a thread about what
happens to those who start reading it...

> - Alex (who seems to have spawned quite the tempest)

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are