| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2636.1 | can't share client side id's | TOOLEY::B_WACKER | | Fri Apr 20 1990 19:22 | 8 |
| Since widgets are client data structures they can't be shared between
processes unless you could convince the toolkit to put them in shared
memory and then the addresses would be garbage.
I think you'll need to set up a messaging system between the processes
and let the widget owner do all the widget manipulations in response
to messages from the subprocess. Mailboxes and shared memory are good
communication media.
|
| 2636.2 | Might even be better... | TCC::BLUEJAY | On the back side of the power curve | Sat Apr 21 1990 10:32 | 8 |
| Who knows..
It might even run faster on multiprocessors that way (one process
manipulating the widgets, another calculating how the widgets should be
manipulated), if done with skill&daring (as oppposed to
ineptitude&cowardice).
- Bluejay Adametz
|
| 2636.3 | Use client/server model | OSLACT::OLAV | Do it in parallel! | Mon Apr 23 1990 11:59 | 6 |
| Now when you have the chance you should use the client/server model in the
application. Write a client doing all the user interface (DECwindows) which
communicates with the server piece of the application. Then you have the full
flexibility over where you want to run the different parts of the application.
Olav
|
| 2636.4 | pushing the state-of-the-art | RIKKA::PALO | Allt � einu �g vissi �g g�ti gert �a�! | Mon Apr 23 1990 13:53 | 8 |
|
Perhaps you should wait until CMA (the Concert Multithreaded Architecture)
comes when you could do your redesign to eliminate the subprocess and to
[naturally] use threads at the same time as inserting DECwindows support.
Threads share a single address space! In addition, CMA is a portable solution
(Digital's offering will be on all of its critical platforms -- VMS, Un*x, etc)...
rikki
|
| 2636.5 | If you want more discussion, we can take this off-line | CLTMAX::dick | Schoeller - Failed Xperiment | Mon Apr 23 1990 14:06 | 21 |
| Paul,
Somewhere (perhaps in dw_examples?), Steve Klein posted a package which provides
pseudo-widget capability for things for which you only know the window_id.
You could use this to allow the sub-processes to know about the main windows.
I would then create all dialog boxes from the sub-processes (rather than the
main process) as children of the pseudo-widgets. The only problem you might
run into is with scroll-bars on the main windows. These would have to be
handled in the main process and pass the data through client messages or some
such to the sub-process.
Knowing what I know about VLS and Compass, I am not going to suggest that you
wait for anything for a means to modify VLS. Knowing what I know about CMA
and the Toolkit, I would suggest that you look at using CMA for Compass though
you will have to be very careful when you do (Xt and CMA don't mix easily or
well).
In any case, you will not be able to use the main processes widget IDs in the
sub-process for the reason that you already noted.
Dick
|
| 2636.6 | CMA and Multiprocess Communication | CADSE::CONCORDIA | | Mon Apr 23 1990 14:27 | 23 |
|
RE: .1, .2, .3
We do already have a mailbox and shared memory mechanism in place for other
purposes, but we would rather not add the overhead of messages for all
the I/O that we do. The other alternative we have been investigating is
to pull the system in to one process. This is promising, but the image/data
size could reach well over 150Mb (again a performance problem).
RE: .4
We had looked at CMA to solve another internal problem with the way that our
system operates, but the indication we had was that the delivery date
would be too late for our needs. Is there a supported version of CMA
available today? CMA would also be ideal as we are porting to RISC also.
Just can't resist the DS5000!!!!
It is our understanding that we will not run into the same promblem under
Ultrix, is this true?
-Thanks, Dave
|
| 2636.7 | CMA available internally for VMS, don't know about ULTRIX | 4GL::SCHOELLER | Who's on first? | Mon Apr 23 1990 20:09 | 17 |
| CMA is definitely available for internal use (we're using it). Is VLS
going to stay around that long that you want to look at rearchitecting it
that greatly? If you go with CMA, you will have to make sure that all
X/DECwindows access is MUTEXed (only 1 thread at a time can safely make
X or Xt calls of any kind).
Unless you opertate in a single address space (threads or something like it)
you can't share widgets. The widget data structures exist in the address
space of the client not the server. VMS or ULTRIX makes no difference.
If you go with CMA, you will probably run into the large address space
problems that you mentioned. I am not sure if there is any way around that
with widgets (other than perhaps the pseudo-widget hack fro Steve Klein).
Good luck, you're going to need it.
Dick
|
| 2636.8 | Same problem on Ultrix? | CADSE::NORMAN | | Tue Apr 24 1990 11:48 | 5 |
| We also have to port this mess (VLS) to Ultrix. Are we going to
end up with the same problem there? Are DECwindows widget IDs
known across forks?
PMN
|
| 2636.9 | | PSW::WINALSKI | Careful with that VAX, Eugene | Tue Apr 24 1990 21:57 | 3 |
| Ultrix should have exactly the same behavior.
--PSW
|
| 2636.10 | how does fork work? | CLTMAX::dick | Schoeller - Failed Xperiment | Wed Apr 25 1990 12:58 | 4 |
| If you can fork processes within the same address space then you may be able
to look at the widgets. However, you then run into reentrancy problems.
Dick
|
| 2636.11 | | FLUME::dike | | Wed Apr 25 1990 13:58 | 7 |
| fork copies the address space, so you get the same data structures. You also
get to share file descriptors, notably the X connection, which will lead to
trouble.
vfork doesn't copy the address space, but the parent is put to sleep until the
chile execs or exits.
Jeff
|