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

Andy Bakun (abakun@scinc.com)
Tue, 29 Jul 1997 15:59:48 -0500

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    If I have a loop that prompts the user (via $command_utils:yes_or_no) as to
    if a certain command should be executed for them (which will happen via
    force_input(), but I don't explictly say that in the prompt)... well, this
    would best be explained with a code example:

    for cmd in (commands)
      ok = $command_utils:yes_or_no("Execute ", command, "?");
      ok && force_input(player, cmd);
    endfor

    (The enclosing loop in actually in a different (enclosing) verb)

    Now, :yes_or_no uses read() (is there another way?) which reads the input
    buffer, which force_input() feeds.  Unfortunately, this doesn't work, since
    the force_input()'ed command in response to the first question becomes the
    answer to the second.  With an odd number of elements in "commands", the
    last one will be executed, but with an even number of elements/iterations,
    of course, you only have to answer (er, type in) half the responses, the
    submitted command gets interpreted as a negative response to the next
    :yes_or_no, and in general, nothing worthwhile happens (worthwhile here
    being a command you answered 'yes' to being executed).

    I considered using suspend() after force_input()ing the command, thereby
    giving the server a chance to do network I/O and creating a new command
    task for it, but that means I can't use :yes_or_no (er, read()) on
    subsiquent iterations.  What I first thought of doing was doing a suspend()
    with no args (to suspend indefinately), but force_input()ing two lines,
    instead, one which was the command to execute, and other which would end up
    resuming the task which is indefinately suspended (but this has the same
    problem, what with not being able to read() from suspended tasks()).

    Note that there actually is the case where the code could suspend(), but
    because of the read(), which restores ticks/seconds limit, it never does
    suspend().

    Any way around this, short of buffering all the commands to force_input at
    the end of the loop?