[Vm-dev] Re: Delays should wakeup the idle process (patch)
johnmci at smalltalkconsulting.com
Sat Jul 16 17:27:02 UTC 2011
Having ported Flow to OS-9 I can agree on all this.
Historical issues were
(a) pthread_cond_timedwait was a pthread_cond_timedwait_NP meaning
platform specific, maybe that is no longer the case.
(b) select() was supported everywhere
(c) resistance to change
(d) Smalltalk socket implementation has to change (see (c))
(e) Heck I even wrote a translation later for Flow to old socket layer.
Maybe in this decade someone can take another run at it given the JIT
can way outrun the poor socket implementation.
On Sat, Jul 16, 2011 at 5:08 AM, Craig Latta <craig at netjam.org> wrote:
> Hi John--
>> The pthread_cond_timedwait (yes I did that years back) won't fly
>> because you miss the interrupt from socket/files/UI which leaves to
>> the odd behavior if squeak is busy good web server, if squeak is idle
>> the bad web server... "it always sends at 50 packets per second "
> In Spoon (the Flow plugin, really), when I signal an external
> semaphore associated with a socket or whatever when activity happens, I
> also signal the "activity" mutex that this pthread_cond_timedwait call
> is waiting on. It works fine; in fact, I had to make this work well, to
> wake up frequently for socket activity for remote messaging on headless
> At the time I wrote it, the Unix and Mac VMs remote messaging
> performance was horrible over this very issue. I also experimented with
> alternative calls, including select(), and nanosleep().
> pthread_cond_timedwait() beat them handily. The aioPoll() stuff just
> seems like a confusing mess.
> Also, having this as a named primitive in an external plugin has
> been very convenient, for enabling this sort of experimentation without
> having to restart the virtual machine.
> Craig Latta
> +31 6 2757 7177
> + 1 415 287 3547
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Vm-dev