[MUD-Dev] Re: lurker emerges

["T. Alexander Popiel" <popiel#snugharbor,com>]

In message:  <35CFD8F1.A612AE00#freehold,crocodile.org>
             Vadim Tkachenko <vt#freehold,crocodile.org> writes:
>T. Alexander Popiel wrote:
>> 
>> To recreate my non-blocking I/O library call,
>
>The keyword here is "functionally equivalent".

*nod*

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

Unfortunately, I require (by my own free will, I'll admit) functionality
in non-threaded environments, so the portability doesn't hold for me.
However, we're just getting religious here, so I'll drop it. ;-)

However, this conversation has done much to crystalize why I prefer
the async primitives over the sync ones... I religiously believe that
they map better to the hardware that I commonly use.  Thank you for
catalyzing this insight.

>nor Java semaphores (they don't exist there)

*blink blink*

I suppose not, in the strictest sense, but I use the following
construct all the time:

  Object sem = new Object();
  synchronized (sem) {
    /* pass sem to some other thread */
    sem.wait();
  }

  ...

  /* some other thread */
  synchronized (sem) { sem.notify(); }

Tastes like a semaphore to me. ;-)

>Please remind me, how do you wait in the programming environment which
>doesn't have the synchronized methods like Java does?

In any timesharing environment, you inform the scheduler that you
should not be rescheduled until a specified event occurs.  If the
OS kernel is doing the scheduling, then this eventually devolves
to a system call.  Some languages (like Java) hide scheduler
interactions behind language constructs.  (For more info on how
Java does it, I suggest looking at the Java VM Spec, specifically
monitorenter, monitorexit, and some of the compilation examples.)

- Alex