Re: [Help-smalltalk] 1.96 news

[Simon Britnell]

Guess I should have commented out the onStartup send
rather than re-introduce the method then.  I looked at
the code and guessed that #returnedFrom... was only
going to be relevant when reloading the image from
disk.  Guessed wrong :)

On to another subject, I'm beginning to examine the
issues with making gst thread safe vis-a-vis calling
into gst from a C thread other than the one that
started the VM (basically, I'm looking for places that
need mutex protection.  The first obvious one is the
call to initSmalltalk and I seem to recall that this
is where I see problems when testing my SDLAudio
callbacks.  Trouble is, the further afield I look ( I
started my trace-back from callin.c ) the more things
that seem to need some attention.

By day, I'm a mild mannered Java programmer who
regularly needs to address performance issues on 32
CPU NUMA machines, so I'm sensitive to the fact that
VMs which don't use the underlying OS thread model
tend to get less than their fair share of CPU power
(ie. they usually can only max out a single CPU).

How amenable are you to changes to the VM to make it
scale onto multi CPU machines.  The required changes
are looking non-trivial and I don't even want to think
about them if I'm going to have to maintain my own
branch forever.  Basically, I'd need to reengineer the
process system so that (all|some) of the smalltalk
processes map onto OS threads.

It looks like the threadsafety issue can be solved
with heavy handed application of mutexes, but I'd
rather do the job properly ang get things full
multithread capable.

--- Paolo Bonzini <address@hidden>
wrote:
> As Simon noted, 1.96 deprecated the init blocks
> mechanism, which has been
> superseded by ObjectMemory events, broadcast via
> #update: directly by the


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/