On Wed, Jan 05, 2011 at 09:00:41AM +0100, Igor Stasenko wrote:
On 5 January 2011 04:12, David T. Lewis <lewis@mail.msen.com> wrote:
On Tue, Jan 04, 2011 at 08:03:42PM -0300, Esteban Lorenzano wrote:
ah... I think (if I understood well) the real problem is that OSProcess were implementing it's own aio things and now it is relying (correctly) in AioPlugin... so, before that, it wasn't important if AioPlugin was present, and now it is (btw... UnixOSProcessPlugin don't really need AioPlugin, it switches to an ugly but necessary polling when absent)
Cheers, Esteban
Yes, that's right. The first version of OSProcess (from 1999) had OSProcess and the OSProcessPlugin. Over time, it grew and I split it into packages. Now CommandShell and OSProcess are the image side packages, and OSProcessPlugin, AioPlugin, and XDisplayControlPlugin provide the VM plugin support. All of it is written in Smalltalk, including the plugins.
Originally, CommandShell was part of OSProcess. And originally, AioPlugin and XDisplayPlugin were part of OSProcessPlugin.
CommandShell uses OSProcess (but loads and runs without it). OSProcess uses mainly OSProcessPlugin, but also AioPlugin if available. OSProcess also uses XDisplayControlPlugin when running on X11, expecially to support #forkSqueak.
The X window system is separate from the operating system, therefore the XDisplayControlPlugin is separate from the OSProcessPlugin. The aio functions are separate from the operating system (they are part of Ian's Unix support code, but not OS functions per se), so the AioPlugin is also separate from the OSProcessPlugin.
What i have learned , that AioPlugin should be included in VM, so osprocess plugin will use more elegant way of working :)
At the higher level, things that relate directly to operating system functions and to the representation of OS processes are part of OSProcess. Things that relate to the pipes, unix shell syntax, file name globbing, command line parsing, and shell window display are part of CommandShell.
yes, but it is much nicer to use asynchronous IO for speaking with those pipes etc, than synchronous, because VM don't needs to be (b)locked each time.
Indeed, that is exactly how it works. AioPlugin provides the mechanism for IO event notification to processes in the image that handle the events, reading available data from a pipe in reponse to the IO event. Input file descriptors are set nonblocking (OSProcessPlugin) for input pipes, and the VM never blocks on input. If AioPlugin is not present, asynchronous IO notification is not available, so polling loops are used instead (but still with nonblocking input). In practice, you will not notice much difference between the polling and the asynchronous input approaches, but I do prefer the asynchronous handlers on aesthetic grounds ;) Dave