[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

# Re: read() and force_input()

- Date: Wed, 30 Jul 1997 10:23:24 -0500
- From:
- Cc: moo-cows@the-b.org
- Content-Type: text/plain; charset="us-ascii"
- In-Reply-To: <199707301011.MAA01230@postfix.cs.ruu.nl>
- References: <3.0.1.32.19970729155948.0081cc20@po.scinc.com>

    At 12:11 PM 7/30/97 +0200, you wrote:
    >I actually managed to get this working (if I get your intentions right) with
    >the following code:
    >
    >commands = {":1", ":2", ":3"};
    >for command in (commands)
    >  ok = $command_utils:yes_or_no(tostr("Execute ", command, "?"));
    >  ok && force_input(player, command, 1);
    >  suspend(0);
    >endfor

    I was initially surprised that this worked, but it makes sense now that
    I've reread the docs on read()... the specific part is:

        It is possible to call `read()' many times in the same command task, so
        long as the task does not call `suspend()' or an explicit
        argument is given. The best use for `read()' with an explicit argument
        is in conjunction with `open_network_connection()', if it
        is enabled.

    The operative part being 'an explicit argument is given', which is what
    :yes_or_no does, and what I always do.  Essentially, I've been operating
    under this suspend()ing read() problem for the past two years and it never
    was an issue (and I suspect it rarely is).  I'm embarrassed I overlooked
    this.  Ouch

    Perhaps that last sentence should read "the best use for read() with an
    explict argument is in conjunction with open_network_connection, if it is
    enabled, or to just get a line of input at any time from any player".

    >the ,1 makes sure the input is entered at the front of the queue, and the
    >suspend(0) gives the server time to dequeue the command. I tested it and it
    >seemed to work fine for me.

    Yeah, this is important, so the server will create a command task for it on
    the next network i/o handling, and it won't get stuck in the queue.  It
    does make a difference if you are waiting for the above loop to finish
    though. :)

    Andy.

References:

- MOOcode level race condition with read() and force_input()

- From: Andy Bakun <abakun@scinc.com>

- Re: MOOcode level race condition with read() and force_input()

- From: Pieter-Bas IJdens <pbijdens@students.cs.ruu.nl>

- Prev by Subject: Re: Problem with Checkpoints
- Next by Subject: Request for help, MacGoesMOO
- Prev by thread: Re: MOOcode level race condition with read() and force_input()
- Next by thread: AppleTalk
- Index(es):
  - Subject
  - Thread

Home | Subject Index | Thread Index