Hi Ron.

Happy New Year!

Processes in Squeak are pre-empted. Before every send bytecode, the interpreter checks if an interrupt flag has been set. If so, it re-schedules processes.

There's good information (essentially annotated code) in Chapter 29 of the Blue Book about which processes are scheduled next: http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_chapter29.html#Con.... Essentially, there's an array of processor priorities, each with a list of processes waiting at that priority. I wouldn't personally have designed it that way.

As with Monitors, I don't actually understand them. I just use Semaphores, which I find easy to understand.

Cheers, Michael.

Ron Teitelbaum wrote:

Hi Michael,

Thanks for the feedback. I'm running on winXP.

I'm beginning to understand the Process model better. I think the problem is what you suggested that the threads are not preempted. What I have during my SUnit test is one long program. I've added Processor yield all over and this seems to help some. How exactly it chooses the threads is still a mystery to me. I found Monitor which has a lot of very good functionality. I'm using it to slice up my treads.

The funniest part of all this is that my problem is with testing, not real life. In real life the system would not be running a test, would only have a few threads to worry about and everything would have the processing it needs.

Thanks again for your help!

Ron

...

-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Michael van der Gulik Sent: Sunday, December 24, 2006 3:00 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] Help with Processor Scheduling

Ron Teitelbaum wrote:

...

Hi All,

I was wondering if someone could help me answer a processor scheduling question. I'm running a process to test SSL memory. The data is received by a process running in a thread priority 40. The server is running priority 70. (both in the same image). There is one thread started as dataHandler for each send.

When I run normally everything works fine. I send data and the dataHandler process picks it up and closes down. I'm seeing one send and about one receive before another send. When it's all done everything sent was received.

The problem is that when I leave squeak and click on any other application, what I see is lots of sends but only rarely a receive. Then the application usually freezes up and has lots and lots of sockets open.

Can someone explain to me why a test running and processes scheduled would act so differently if I click on another application?

I tried to look at Processor activePriority hoping that since UI was running at 40 that maybe active priority was raised when Squeak was not the top most application. It appeared to stay at 40.

Thanks for your help and any suggestions on how to diagnose this

problem.

Hi Ron.

Which platform and VM version? On Linux, there's a "-lazy" argument which you can pass to the Squeak VM, which I assume pauses the VM. That's not quite the same behaviour as you're seeing but could be somehow related. On some versions of Windows, the OS will give the active window a higher CPU priority than windows in the background.

Also, I assume you're aware of Squeak's rather... interesting... scheduling behaviour. A process will never be pre-empted by a process running at a higher priority. Rescheduling also only ever happens when some interrupt happens in Squeak - usual sources are timers and (I assume) I/O from places such as the network.

Try stopping the Morphic thread ("the UI process") and observing the behaviour of your program. Obviously you can't do this from Morphic, so I recommend using a debugging tool I wrote called "REPLServer" available from http://www.squeaksource.com/SecureSqueak. It could be that Morphic is causing the reschedules, so that when Morphic stops causing process reschedules, some of your threads never get scheduled to run . You could force processes to be rescheduled by doing "Processor yield" in your code.

I also find that bumping the event poll period gives me a more responsive system when there are busy processes around, but I'm not sure if it will affect your code. I'd be a bit wary if it did! It usually means there's a bug:

EventSensor eventPollPeriod: 50. "Makes the system more reactive under load" Sensor installEventTickler.

And to start up REPLServer:

" Telnet to localhost:4445 when the GUI freezes up. " REPLServer startOn: 4445 named: 'REPLServer' priority: (Processor highIOPriority).

Michael. _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

---

Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography