<!-- 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>