CLIM mail archive
[Prev][Next][Index][Thread]

Using Processes in CLIM

    Date: Mon, 1 Apr 91 18:52:20 PST
    From: Jon L White <jonl%kuwait@lucid.com>

    re: It would be rather awful if the use of documented and supposedly portable
	features of CLIM resulted in applications effectively only being portable 
	to a limited set of implementations which happen to provide a particular 
	tasking model.

    Isn't it the case that CLIM applications will likely only "port" to those
    implementations that are party to the CLIM consortium?  I know that this 
    isn't a "closed" consortium; but not even every vendor with a Symbolics-
    inspired multi-tasking design belongs to it.  Someone can correct me if 
    they really think that CLIM is likely to be working freely and well on, 
    say, MACL 2.0 (the Apple Common Lisp).

As a matter of fact, CLIM has been run well under MACL 2.0.
CLIM itself was designed to take advantage of multi-tasking
when available, but *not* to require it.  For example, CLIM's
general stream-input-wait runs the event loop in a single
process environment or waits for an event to be delivered
from some other process if we're multi-tasking.  This allows
for more successful debugging in multi-process environments
but retains complete portability of the CLIM layer.

As another example, the application-launching substrate takes
a keyword argument :WAIT-UNTIL-DONE, which allows the
programmer to indicate whether or not a particular
application is being invoked for a specific return value or
whether it's an ancillary application.  (Consider invoking a
special-purpose graphics editor to edit a picture that's
contained inside a text editor buffer.  Sometimes the initial
editor wants that to happen synchronously.)  This does not
allow the programmer to specify that another process should
be used to run the application, but does allow CLIM the
option of using another process when available.

The real issue here is not the portability of CLIM (which has
already been demonstrated to single-process environments),
but the portability of applications which wish to use CLIM.
Anyone writing an application which *requires* multi-tasking
will be hard-pressed to port it to MACL 2.0, no matter what
support CLIM provides.  We have already made his life easier
by providing a common interface to the multitude of existing
Lisp implementations of multiple processes (and we can make
it better by separating that set of functions into a
specially named package), but we can't eliminate entirely his
need to be aware of the limitations of his delivery platform.

0,,
Follow-Ups: References:
Main Index | Thread Index