Wait a sec

I have an asynchronous process (socket-related) that I want to start, then
wait a second for it to complete, and then get the results.  Something like:

    socket connect.
    <wait a second>.
    socket response.

'Processor sleep: 1000' doesn't work because (I assume) it's putting
everything to sleep so it's not a real delay (in terms of this example) and
so 'socket response' returns nil.  I'm looking for something that will work
in a workspace, i.e., I can execute the three lines of code at one time and
get a result, as opposed to something intended for an application (e.g.,
event handling, forked processes, etc).  Hopefully this makes sense ... and
thanks in advance.

-- Louis

Louis Sumberg wrote:
> I have an asynchronous process (socket-related) that I want to start, then
> wait a second for it to complete, and then get the results.  Something
> like:
>
>     socket connect.
>     <wait a second>.
>     socket response.

I assume that your problem here is that you are putting the main Process to
sleep, hence it does not service the Windows event queue, hence the events
underlying the Sockets implementation are not handled.

I had a similar problem writing test cases for something that needed to "sleep"
for a defined time while it waited to see if it got notified of external
actions.  The way I do it is to do:

 self pumpMessagesFor: 5000.    "millis"

in the test.  Where #pumpMessagesFor: is defined as:

========================
pumpMessagesFor: anInteger
    "if we are the main loop then pump windows messages
    for anInteger number of milliseconds whilst ignoring
    keyboard and mouse input.  Returns after the specified
    delay.
    This is used to wait for callbacks without blocking the main loop"

    | loop |

    loop := Processor activeProcess isMain
                    ifTrue: [ModalMsgLoop new]
                    ifFalse: [Semaphore new].

    [(Delay forMilliseconds: anInteger) wait. loop signal] fork.

    loop wait.

========================

Perhaps something similar would work for you.

    -- chris

Chris,

Thank you thank you thank you.  It works perfectly.

When I first saw what you wrote, I thought "ModalMsgLoop?  What the hell is
that?", and then I saw (via DSDN) that in the notes for release 3.03 there's
an enhancement - "New ModalMsgLoop synchronisation object can be used to
block UI process without starting a new one."

I'm hoping to use this for unit tests, something I'm not famous for writing.
(The actual application uses observers and events so it's not needed there.)
Again, thank you thank you thank you :)

-- Louis

Chris,

A little update on #pumpMessagesFor: It works fine in a workspace but when I
ran some unit tests, the unit browser just hangs.  If I move the mouse a
little then it runs the first test, move the mouse again and it runs the
second, and so on, for the tests that use #pumpMessagesFor:.  So ... I
inserted 'SessionManager inputState prod' (after 'loop signal', within the
block) and now it works fine.  Why it works for you (without #prod) in your
unit tests and not for me, I have no idea.

-- Louis

Louis Sumberg wrote:

> A little update on #pumpMessagesFor: It works fine in a workspace but
> when I ran some unit tests, the unit browser just hangs.  If I move the
> mouse a little then it runs the first test, move the mouse again and it
> runs the second, and so on, for the tests that use #pumpMessagesFor:.  So
> ... I inserted 'SessionManager inputState prod' (after 'loop signal',
> within the block) and now it works fine.  Why it works for you (without
> #prod) in your unit tests and not for me, I have no idea.

Aha!  Thanks.

As far as I can see, it never did work properly for me either.  (The sequence
of tests that use it takes a fairly long time, so I must always have got bored
waiting and started waving the mouse around without niticing the side-effect).

Thinking about it, it seems to me that this is a bug in
ModalMessageLoop>>signal, and that it should #prod the SessionManager
inputState after setting the 'loop' flag.  Anyway that's the change I've made
to my image, rather than "fixing" #pumpMessagesFor:.

Blair, can you confirm that that's bug ?   (No SUnit test for this one;-)

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> Thinking about it, it seems to me that this is a bug in
> ModalMessageLoop>>signal, and that it should #prod the SessionManager
> inputState after setting the 'loop' flag.  Anyway that's the change I've
made
> to my image, rather than "fixing" #pumpMessagesFor:.
>
> Blair, can you confirm that that's bug ?   (No SUnit test for this one;-)
>

I'll take your word for it since it certainly seems to be - recorded as
#1550. ModalMsgLoop could do with a class comment as well.

Regards

Blair