Re: [Pharo-project] Pharo and CommandShell on OSX ?
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
but 2) None of the commands get executed. If I try the stuff which will eval inside squeak/pharo, then that's fine (Eg; stdout nextPutAll: 'hello world'; cr.). However, if I try a command such as 'ls' or 'who', all hell breaks lose. stack trace follows :)
If I am doing anything obviously wrong, please feel free to hit me over the head :)
Nope, it's not you, it's the plugin included with your VM. Some of the Mac VMs in circulation were accidentally built with a very out of date version of the OSProcessPlugin. Apparently you have one of them, and it will definitely not work. But I think there is a newer version (4.2.5 IIRC) that has the up to date plugin that works properly on Mac.
Dave
Regards S.
3 January 2011 6:49:43 pm
VM: Mac OS - intel - 1065 - Squeak3.8.1 of '28 Aug 2006' [latest update: #6747] Squeak VM 4.2.4b1 Image: Pharo-1.1-11406-rc3 [Latest update: #11406]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/stef/squeak/SeaSide-3.0 Trusted Dir /foobar/tooBar/forSqueak/bogus Untrusted Dir /Users/stef/Library/Preferences/Squeak/Internet/My Squeak
UndefinedObject(Object)>>mustBeBooleanIn: Receiver: nil Arguments and temporary variables: context: BufferedAsyncFileReadStream>>moveAvailableDataFrom: proceedValue: nil Receiver's instance variables: nil
UndefinedObject(Object)>>mustBeBoolean Receiver: nil Arguments and temporary variables:
Receiver's instance variables: nil
BufferedAsyncFileReadStream>>moveAvailableDataFrom: Receiver: BufferedAsyncFileReadStream: 'pipeReader' Arguments and temporary variables: sqFile: #[48 205 236 155 72 91 120 160 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0] bufferSize: 1000 buffer: '...etc... count: #(0) Receiver's instance variables:
BufferedAsyncFileReadStream>>moveAvailableDataToBuffer Receiver: BufferedAsyncFileReadStream: 'pipeReader' Arguments and temporary variables:
Receiver's instance variables:
BufferedAsyncFileReadStream>>update: Receiver: BufferedAsyncFileReadStream: 'pipeReader' Arguments and temporary variables: aParameter: a PseudoAioEventHandler Receiver's instance variables:
[] in PseudoAioEventHandler(Object)>>changed: Receiver: a PseudoAioEventHandler Arguments and temporary variables: aParameter: BufferedAsyncFileReadStream: 'pipeReader' aDependent: a PseudoAioEventHandler Receiver's instance variables: dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc...
DependentsArray>>do: Receiver: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') Arguments and temporary variables: aBlock: [:aDependent | aDependent update: aParameter] dep: BufferedAsyncFileReadStream: 'pipeReader' i: 1 iLimiT: 1 Receiver's instance variables: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader')
PseudoAioEventHandler(Object)>>changed: Receiver: a PseudoAioEventHandler Arguments and temporary variables: aParameter: a PseudoAioEventHandler Receiver's instance variables: dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc...
PseudoAioEventHandler(Object)>>changed Receiver: a PseudoAioEventHandler Arguments and temporary variables:
Receiver's instance variables: dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc...
[] in [] in PseudoAioEventHandler>>eventGeneratorProcess Receiver: a PseudoAioEventHandler Arguments and temporary variables: d: a Delay(125 msecs) Receiver's instance variables: dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc...
BlockClosure>>repeat Receiver: [self changed. d wait] Arguments and temporary variables:
Receiver's instance variables: outerContext: [] in PseudoAioEventHandler>>eventGeneratorProcess startpc: 59 numArgs: 0
[] in PseudoAioEventHandler>>eventGeneratorProcess Receiver: a PseudoAioEventHandler Arguments and temporary variables: d: a Delay(125 msecs) Receiver's instance variables: dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc...
[] in BlockClosure>>newProcess Receiver: [[self changed. d wait] repeat] Arguments and temporary variables:
Receiver's instance variables: outerContext: PseudoAioEventHandler>>eventGeneratorProcess startpc: 54 numArgs: 0
--- The full stack --- UndefinedObject(Object)>>mustBeBooleanIn: UndefinedObject(Object)>>mustBeBoolean BufferedAsyncFileReadStream>>moveAvailableDataFrom: BufferedAsyncFileReadStream>>moveAvailableDataToBuffer BufferedAsyncFileReadStream>>update: [] in PseudoAioEventHandler(Object)>>changed: DependentsArray>>do: PseudoAioEventHandler(Object)>>changed: PseudoAioEventHandler(Object)>>changed [] in [] in PseudoAioEventHandler>>eventGeneratorProcess BlockClosure>>repeat [] in PseudoAioEventHandler>>eventGeneratorProcess [] in BlockClosure>>newProcess
On 4 January 2011 17:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, Â So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
 I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
 1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
was this plugin included into standard vms once before? because currently its not and i don't remember if i built VMs it . -- Best regards, Igor Stasenko AKA sig.
On Tue, Jan 04, 2011 at 07:15:14PM +0100, Igor Stasenko wrote:
On 4 January 2011 17:34, St??phane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, ?? So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
?? I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
?? 1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
was this plugin included into standard vms once before? because currently its not and i don't remember if i built VMs it .
It has never been included in any Mac VMs, and I do not know if it works on Mac. But I expect that it will work because the Mac VM uses a copy of Ian's aio support code for the unix VM. Dave
Hi, Yes, 4.2.5 and exuperi both has UnixOSProcessPlugin as default (and I understand that, they are very needed :) ) Cheers, Esteban El 04/01/2011, a las 3:15p.m., Igor Stasenko escribió:
On 4 January 2011 17:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
was this plugin included into standard vms once before? because currently its not and i don't remember if i built VMs it .
-- Best regards, Igor Stasenko AKA sig.
On 4 January 2011 23:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, Yes, 4.2.5 and exuperi both has UnixOSProcessPlugin as default (and I understand that, they are very needed :) )
Err.. i asked about AioPlugin. Yes, OSProcessPlugin is quite useful , since with it we can perform some OS-specific tasks directly from smalltalk code. Someday it will rock, especially when we will have something better than FileDirectory & friends :)
Cheers, Esteban
El 04/01/2011, a las 3:15p.m., Igor Stasenko escribió:
On 4 January 2011 17:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, Â So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
 I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
 1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
was this plugin included into standard vms once before? because currently its not and i don't remember if i built VMs it .
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
he, we already have something A LOT better: Filesystem. I would like it to become the default Pharo file manager :( El 04/01/2011, a las 7:10p.m., Igor Stasenko escribió:
On 4 January 2011 23:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, Yes, 4.2.5 and exuperi both has UnixOSProcessPlugin as default (and I understand that, they are very needed :) )
Err.. i asked about AioPlugin.
Yes, OSProcessPlugin is quite useful , since with it we can perform some OS-specific tasks directly from smalltalk code.
Someday it will rock, especially when we will have something better than FileDirectory & friends :)
Cheers, Esteban
El 04/01/2011, a las 3:15p.m., Igor Stasenko escribió:
On 4 January 2011 17:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
was this plugin included into standard vms once before? because currently its not and i don't remember if i built VMs it .
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Jan 4, 2011, at 11:59 PM, Esteban Lorenzano wrote:
he, we already have something A LOT better: Filesystem. I would like it to become the default Pharo file manager :(
yes this is the idea. Now I should check that colin merge the fixes of lukas and get an update about the streams dependencies.
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 El 04/01/2011, a las 7:10p.m., Igor Stasenko escribió:
On 4 January 2011 23:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, Yes, 4.2.5 and exuperi both has UnixOSProcessPlugin as default (and I understand that, they are very needed :) )
Err.. i asked about AioPlugin.
Yes, OSProcessPlugin is quite useful , since with it we can perform some OS-specific tasks directly from smalltalk code.
Someday it will rock, especially when we will have something better than FileDirectory & friends :)
Cheers, Esteban
El 04/01/2011, a las 3:15p.m., Igor Stasenko escribió:
On 4 January 2011 17:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
was this plugin included into standard vms once before? because currently its not and i don't remember if i built VMs it .
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
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. 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. Dave
El 04/01/2011, a las 7:10p.m., Igor Stasenko escribi?:
On 4 January 2011 23:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, Yes, 4.2.5 and exuperi both has UnixOSProcessPlugin as default (and I understand that, they are very needed :) )
Err.. i asked about AioPlugin.
Yes, OSProcessPlugin is quite useful , since with it we can perform some OS-specific tasks directly from smalltalk code.
Someday it will rock, especially when we will have something better than FileDirectory & friends :)
Cheers, Esteban
El 04/01/2011, a las 3:15p.m., Igor Stasenko escribi?:
On 4 January 2011 17:34, St?phane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 4, 2011, at 4:25 AM, David T. Lewis wrote:
On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote:
Hello Everyone, So, long time squeaker, first time pharo(er ?). Please don't hold this against me ;)
I am trying to get CommandShell loaded into Pharo (using the Seaside Image) via Monticello. I have tried this on Pharo 1.1/1.1.1/1.2 for the record (same thing). I skip past the MVC/Morphic errors about PluggableList etc, and I can get the command shell to pop-up, however, two things happen;
The CommandShell package on SqueakSource is also now broken down into sub-packages, so you can load the individual parts if you want. But just proceding through the MVC warnings as you did is harmless.
1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning
AFAIK, noone has tried building the AioPlugin for Mac, so you will get this warning when running on a Mac. But as you say, it's just a warning.
I imagine that we will see that with igor and the automatic build too.
was this plugin included into standard vms once before? because currently its not and i don't remember if i built VMs it .
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
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.
Dave
-- Best regards, Igor Stasenko AKA sig.
Ok a couple of years back Eliot had me compile up a AioPlugin for os-x I've send that to Esteban Lorenzano. I note that from a plugin perspective os-x is well unix. The os-x application loader code will either take a bundle or a library etc etc. it really doesn't care what form the binary is from pure ancient unix to post modern os-x bundle. Some people *think* os-x is special, well yes/no, it's is unix, yet the UI isn't x-windows so various things in osprocess won't fly, forking a UI based app freaks things out as it's ok for x-windows but that concept is lost on window server. Still the aioplugin as a bundle or dynlib, we don't care. On 2011-01-05, at 12:00 AM, Igor Stasenko wrote:
What i have learned , that AioPlugin should be included in VM, so osprocess plugin will use more elegant way of working :)
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
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
participants (5)
-
David T. Lewis -
Esteban Lorenzano -
Igor Stasenko -
John M McIntosh -
Stéphane Ducasse