[Vm-dev] reducing the gap - ioProcessEvents()

K K Subbu kksubbu.ml at gmail.com
Sun May 14 07:28:54 UTC 2017


On Friday 12 May 2017 11:52 PM, Ben Coman wrote:
>
> Its great that Pharo is back-in-the fold building out of the OpenSmalltalk repo,
> but I wonder if we could be even closer, by trying to minimise the
> number of  "#ifdef PharoVM".
>
> Perhaps sqUnixMain.c is a good candidate.
> To help analysis I ran the file through unifdef [1] and diff'd it here... .
> * https://www.diffchecker.com/MO0KHNpH
>
> One preliminary question...
>    what is the return value of ioProcessEvents() used for?
> Apart from this line in sqUnixMain.c...
>    result = dpy->ioProcessEvents();
> the rest of the codebase seems to discard the return value...
> * https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=ioProcessEvents&type=
>
> Now where Pharo always returns 0 from ioProcessEvents()
> would that be a problem for Squeak?
>
> So would Squeak be interested in adopting Pharo's flexible ioProcessEvents()?

The context starts here in pharo-project :
 
https://lists.gforge.inria.fr/pipermail/pharo-project/2012-September/069448.html
and then moved onto vm-dev at:
 
http://lists.squeakfoundation.org/pipermail/vm-dev/2012-September/011347.html

As far as I could make out, the change was made to delay handling i/o 
events till the first host window is created and the image is ready to 
process events. This gives more flexibility like multi-window, native 
window integration etc, but it breaks old images which depend on the VM 
for handling window events.

Regards .. Subbu


More information about the Vm-dev mailing list