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 <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
In reply to this post by Igor Stasenko
On Wed, Jan 05, 2011 at 09:00:41AM +0100, Igor Stasenko wrote:
> On 5 January 2011 04:12, David T. Lewis <[hidden email]> 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 |
In reply to this post by EstebanLM
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. > |
Free forum by Nabble | Edit this page |