BlockingCallMonitor

Hello,

I'm playing with a BlockingCallMonitor on a ServerSocket.

---------------------
serverSocket := ServerSocket port: port.

monitor := BlockingCallMonitor new
    callBlock: [ serverSocket accept ];
    completionBlock: [ :socket | {socket processing code} ];
    priority: Processor activePriority + 1;
    monitor;
    yourself.

{some code}
---------------------

{socket processing code} does not called until {some code} execution ends.
How can I fix it?

--
Dmitry Zamotkin

Dmitry,

> {socket processing code} does not called until {some code} execution ends.
> How can I fix it?

The first two things that come to mind are the relevant Smalltalk Process
priorities, and possible hard blocks/timeouts in Winsock.  I'd check the
priorities first.  You've specified the active priority plus one; it could
simply be that the remainder of you code is not being scheduled because of
that.  I use Processor userBackgroundPriority for most worker threads; that
might fix your problem.

Failing that, your machine might be drawing a blank for a while and then
moving forward after a timeout.  OA has implemented overlapped connect calls
for a while now; that was an important fix, especially when networking peer
workstations where some of them can easily be turned off.  We might still be
vulnerable to hard blocks on DNS, but, one would have to encounter either a
misconfigured machine or a pretty serious network problem for that to be an
issue, so I'm not terribly worried about it.  You can rule that out by using
a hosts file to ensure that the names and numbers match. and are quickly
resolvable.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:9t3d0j$49og$[hidden email]...
> Dmitry,
>
> > {socket processing code} does not called until {some code} execution
ends.
> > How can I fix it?
>
> The first two things that come to mind are the relevant Smalltalk Process
> priorities, and possible hard blocks/timeouts in Winsock.  I'd check the
> priorities first.  You've specified the active priority plus one; it could
> simply be that the remainder of you code is not being scheduled because of
> that.  I use Processor userBackgroundPriority for most worker threads;
that
> might fix your problem.

Thanks, Bill it really solves a problem!

--
Dmitry Zamotkin