<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: lurker emerges -->
<!--X-From-R13: Hnqvz Fxnpuraxb <igNserrubyq.pebpbqvyr.bet> -->
<!--X-Date: Mon, 10 Aug 1998 22:39:18 -0700 -->
<!--X-Message-Id: 35CFD8F1.A612AE00#freehold,crocodile.org -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199808110445.VAA07689#cashew,snugharbor.com.snugharbor.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: lurker emerges</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:vt#freehold,crocodile.org">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00652.html">Previous</a>
| <a href="msg00654.html">Next</a>
]
Thread:
[ <a href="msg00652.html">Previous</a>
| <a href="msg00658.html">Next</a>
]
Index:
[ <A HREF="author.html#00653">Author</A>
| <A HREF="#00653">Date</A>
| <A HREF="thread.html#00653">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: lurker emerges</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: lurker emerges</LI>
<LI><em>From</em>: Vadim Tkachenko <<A HREF="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</A>></LI>
<LI><em>Date</em>: Tue, 11 Aug 1998 00:38:57 -0500</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
[Funny, I didn't see my post, but see yours???]
T. Alexander Popiel wrote:
>
> In message: <<A HREF="msg00649.html">35CFBD79.68748E69#freehold,crocodile.org</A>>
> Vadim Tkachenko <vt#freehold,crocodile.org> writes:
[skipped]
> >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).
>
> If I'm reading this correctly, your asyncread() creates a semaphore,
> spawns a thread, associates the two, and returns immediately. The
> spawned thread does the actual blocking read, then notifies the
> semaphore and exits.
>
> To recreate my non-blocking I/O library call, you've added the
> overhead of semaphore creation and destruction (and a possible
> semaphore leak if the caller does not dispose of the semaphore
> properly), and thread creation and destruction, all to end up
> with something functionally equivalent to what I wanted in the
> first place.
The keyword here is "functionally equivalent".
> Personally, I don't see this as a win.
Neither do I, but what's important to me is a portability. Can you agree
that you can encapsulate all this stuff so whatever the implementation
is you can keep the interface the same? And, this way or that, using
semaphores as a standard way of event notification really helps to keep
the logical structure consistent. Actually, the semaphores I use in Java
are neither the underlying OS semaphores nor Java semaphores (they don't
exist there), but something I made up - they're [hopefully] lighter than
actual OS ones.
> Especially on systems (like SunOS 4.1.3) which don't support threading at
> all, making what you suggest well nigh impossible.
I see your point, but since I've been trying to program the parallel
stuff in DOS and Windows and then came to multithreaded OS/2 (it was
before I saw a first live UNIX box), I vowed not to use
non-multithreaded systems for parallel system development. This is my
personal preference, nothing more.
> >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.
>
> I think the only difference is in performance and the a stylistic
> preference in choice of primitives. I prefer async primitives,
I _use_ them, too, but on the higher level - usually, I use the blocking
read/write below the readObject/writeObject level, and sems and threads
above
> because sync can be built on async with trivial performance loss
> (two routine calls (request, wait) instead of one),
It may be Java-specific, but what really annoys me is a variety of ways
to tell me what was the result of async operation - some return -1, some
null, some throw exception... Please remind me, how do you wait in the
programming environment which doesn't have the synchronized methods like
Java does? I remember, in OS/2 I was using the threads and mutexes
anyway, maybe some async operations were supporting the callback
routines, which is not elegant anyway... What am I missing here?
> while async can be built on sync only with lots of other cruft (semaphores,
> threads)
This may be arguable, but I (1) consider the semaphores a standard and
reusable way to communicate between event producers and consumers
(mutexes for locking, not actually applicable in Java) (2) consider the
multi-threading the more _logical_ architecture than the single-threaded
one. I usually sacrifice performance for clarity, - you can always
optimize the code later, but if you make your system consisting of small
patches here and there, nothing will help to prevent it from falling
apart.
> and large performance loss.
Depending on where you draw the line between the sync and async. Mine is
pretty high.
> >> 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.
>
> A solution which only works if you have a multithreaded environment...
> which I don't. :-(
See above.
> - Alex
--
Still alive and smile stays on,
Vadim Tkachenko <vt#freehold,crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00658" HREF="msg00658.html">[MUD-Dev] Re: lurker emerges</A></strong>
<ul compact><li><em>From:</em> "T. Alexander Popiel" <popiel#snugharbor,com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00652" HREF="msg00652.html">[MUD-Dev] Re: lurker emerges</A></STRONG>
<UL><LI><EM>From:</EM> "T. Alexander Popiel" <popiel#snugharbor,com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00652.html">[MUD-Dev] Re: lurker emerges</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00654.html">[MUD-Dev] Re: lurker emerges</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00652.html">[MUD-Dev] Re: lurker emerges</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00658.html">[MUD-Dev] Re: lurker emerges</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00653"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00653"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: lurker emerges</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00611" HREF="msg00611.html">[MUD-Dev] Re: lurker emerges</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Mon 10 Aug 1998, 05:23 GMT
<UL>
<LI><strong><A NAME="00632" HREF="msg00632.html">[MUD-Dev] Re: lurker emerges</A></strong>,
T. Alexander Popiel <a href="mailto:popiel#snugharbor,com">popiel#snugharbor,com</a>, Mon 10 Aug 1998, 15:29 GMT
<UL>
<LI><strong><A NAME="00649" HREF="msg00649.html">[MUD-Dev] Re: lurker emerges</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Tue 11 Aug 1998, 03:41 GMT
<UL>
<LI><strong><A NAME="00652" HREF="msg00652.html">[MUD-Dev] Re: lurker emerges</A></strong>,
T. Alexander Popiel <a href="mailto:popiel#snugharbor,com">popiel#snugharbor,com</a>, Tue 11 Aug 1998, 04:45 GMT
<UL>
<LI><strong><A NAME="00653" HREF="msg00653.html">[MUD-Dev] Re: lurker emerges</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Tue 11 Aug 1998, 05:39 GMT
<LI><strong><A NAME="00658" HREF="msg00658.html">[MUD-Dev] Re: lurker emerges</A></strong>,
T. Alexander Popiel <a href="mailto:popiel#snugharbor,com">popiel#snugharbor,com</a>, Tue 11 Aug 1998, 15:05 GMT
<LI><strong><A NAME="00676" HREF="msg00676.html">[MUD-Dev] Re: lurker emerges</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Wed 12 Aug 1998, 04:33 GMT
</LI>
</LI>
</LI>
<LI><strong><A NAME="00656" HREF="msg00656.html">[MUD-Dev] Re: lurker emerges</A></strong>,
Petri Virkkula <a href="mailto:pvirkkul#iki,fi">pvirkkul#iki,fi</a>, Tue 11 Aug 1998, 07:53 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00654" HREF="msg00654.html">[MUD-Dev] Re: lurker emerges</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Tue 11 Aug 1998, 06:48 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
</ul>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>