IPC with Squeak
Locked
 
|
Dear all,
here's a little scenario for which I can imagine an implementation that I don't like, though. A process is talking to a running Squeak VM/image, sending it requests. Squeak responds. Through what channels could both requests and responses be sent? I can imagine using networking (sockets), but since the process and Squeak VM will surely be running on the same machine, that seems a little bit exaggerated. Are there other ways of doing IPC with Squeak that exist in the form of a loadable package? (Or would they have to be implemented?) Best, Michael |
|
|
On Jan 2, 2008, at 22:10 , Michael Haupt wrote:
> Dear all, > > here's a little scenario for which I can imagine an implementation > that I don't like, though. > > A process is talking to a running Squeak VM/image, sending it > requests. Squeak responds. Through what channels could both requests > and responses be sent? > > I can imagine using networking (sockets), but since the process and > Squeak VM will surely be running on the same machine, that seems a > little bit exaggerated. Are there other ways of doing IPC with Squeak > that exist in the form of a loadable package? (Or would they have to > be implemented?) Which platforms do you need to support? IPC is inherently platform- dependent. Sockets aren't all that bad I'd say, it's a standard way of doing IPC. Ian's new Socket Plugin supports all socket families so you do not have to use network sockets. Has not been tested on non-Unix platforms yet AFAIK, though. Another possibility would be using pipes - I had the OLPC image communicate with a Python wrapper via AsyncFile for a while (we now switched to the DBus plugin). And OSProcess lets you connect processes via stdin/stdout. How would you do it if you were coding in C? - Bert - |
|
|
The os-x carbon vm uses shared unix memory (various flavours of that)
to share a semaphore flag, some coordinates and the squeak screen buffer. The semaphore was needed to prevent race conditions on dual processor machines when squeak is updating the screen buffer, and the browser plugin is frantically tossing draw commands to the browser display surface. Actually the details on how to setup the shared memory space is in typical unix fashion clouded with man pages that don't say how it actually needs to be coded. If not done just quite right, then it doesn't work, so just look at the squeak VM mac os source. For this usage it didn't make sense to shove 180MB a second thru a pipe or socket so that you could have 1024x768 60 fps drawing in the worst case. On Jan 2, 2008, at 1:45 PM, Bert Freudenberg wrote: > On Jan 2, 2008, at 22:10 , Michael Haupt wrote: > >> Dear all, >> >> here's a little scenario for which I can imagine an implementation >> that I don't like, though. >> >> A process is talking to a running Squeak VM/image, sending it >> requests. Squeak responds. Through what channels could both requests >> and responses be sent? >> >> I can imagine using networking (sockets), but since the process and >> Squeak VM will surely be running on the same machine, that seems a >> little bit exaggerated. Are there other ways of doing IPC with Squeak >> that exist in the form of a loadable package? (Or would they have to >> be implemented?) > > Which platforms do you need to support? IPC is inherently platform- > dependent. > > Sockets aren't all that bad I'd say, it's a standard way of doing > IPC. Ian's new Socket Plugin supports all socket families so you do > not have to use network sockets. Has not been tested on non-Unix > platforms yet AFAIK, though. > > Another possibility would be using pipes - I had the OLPC image > communicate with a Python wrapper via AsyncFile for a while (we now > switched to the DBus plugin). > > And OSProcess lets you connect processes via stdin/stdout. > > How would you do it if you were coding in C? > > - Bert - > > > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
|
|
In reply to this post by Bert Freudenberg
On Wed, Jan 02, 2008 at 10:45:56PM +0100, Bert Freudenberg wrote:
> On Jan 2, 2008, at 22:10 , Michael Haupt wrote: > >A process is talking to a running Squeak VM/image, sending it > >requests. Squeak responds. Through what channels could both requests > >and responses be sent? > > And OSProcess lets you connect processes via stdin/stdout. On Unix or OS X you can use CommandShell with OSProcess, so that an external process with stdin/stdout/stderr streams connected to Squeak via OS pipes is for example: (CommandShell pipeableProxyFor: 'ls -l') value Sockets are a good cross-platform approach, and also would be better if you want Squeak to respond to unsolicited connections or to processes that are started independently of Squeak. With respect to performance, as always if you did not measure it then don't assume it's a problem. Sockets and pipes are good enough for most purposes. Dave |
|
|
In reply to this post by Bert Freudenberg
Hi,
thanks to you all for your help. On Jan 2, 2008 10:45 PM, Bert Freudenberg <[hidden email]> wrote: > Which platforms do you need to support? IPC is inherently platform- > dependent. For the time being, Mac (my development platform) would do, but having Linux at the same time certainly wouldn't hurt. Windows would have to be done provided what I have in mind (a) worked, (b) were portable to Windows anyway and (c) were interesting for others. ;-) > Sockets aren't all that bad I'd say, it's a standard way of doing > IPC. Ian's new Socket Plugin supports all socket families so you do > not have to use network sockets. Has not been tested on non-Unix > platforms yet AFAIK, though. Is that pre-installed with the available VMs? > Another possibility would be using pipes - I had the OLPC image > communicate with a Python wrapper via AsyncFile for a while (we now > switched to the DBus plugin). That's probably the standard AsynchFilePlugin, right? > How would you do it if you were coding in C? I'd be asking pretty much the same questions due to lack of experience. :-P Best, Michael |
|
|
On Jan 3, 2008, at 12:34 , Michael Haupt wrote:
> Hi, > > thanks to you all for your help. > > On Jan 2, 2008 10:45 PM, Bert Freudenberg <[hidden email]> > wrote: >> Which platforms do you need to support? IPC is inherently platform- >> dependent. > > For the time being, Mac (my development platform) would do, but having > Linux at the same time certainly wouldn't hurt. Windows would have to > be done provided what I have in mind (a) worked, (b) were portable to > Windows anyway and (c) were interesting for others. ;-) Sockets are pretty portable. >> Sockets aren't all that bad I'd say, it's a standard way of doing >> IPC. Ian's new Socket Plugin supports all socket families so you do >> not have to use network sockets. Has not been tested on non-Unix >> platforms yet AFAIK, though. > > Is that pre-installed with the available VMs? Not yet, you need to build from SVN. >> Another possibility would be using pipes - I had the OLPC image >> communicate with a Python wrapper via AsyncFile for a while (we now >> switched to the DBus plugin). > > That's probably the standard AsynchFilePlugin, right? Yes. >> How would you do it if you were coding in C? > > I'd be asking pretty much the same questions due to lack of > experience. :-P > > Best, > > Michael > - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |