| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2516.1 | Please Don't Do It! | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Tue Mar 27 1990 12:26 | 25 |
| WRONG!!!!!
VAX/UISX absolutely, positively MUST be able to do Xlib calls from
the AST. This product is just entering FT2 and yes, indeed it does
work. There have been and still are a few bugs in Xlib and the
transports, and a couple make the V1 server unreliable, but the
server as of V5.3-1 is reliable (at least reliable enough for UISX).
UISX layers the VWS (the old VMS windowing software) programming
interface -- UIS -- on top of VMS/DECwindows. UIS relies heavily on
the doorbell AST mechanism and most applications are event driven,
emitting Xlib calls generated by user code called as a result of the
event.
If Xlib cannot be called from the doorbell AST, then it's next to
useless. While there might be workarounds, they would be cumbersome
and slow - and would make the product non-viable. If the ability to
do this is removed, or support for it decommitted, then you jepardize
a large revenue stream for hardware depending on having the UIS
application base available.
I also believe that there are real customers using this in the same
way. Probably the customers that forced us to invent it to begin
with.
|
| 2516.2 | | FLUME::dike | | Tue Mar 27 1990 13:43 | 3 |
| It will work right on Ultrix if you use Xlib within the callback. I was very
careful about making sure that worked right.
Jeff
|
| 2516.3 | | DECWIN::FISHER | Prune Juice: A Warrior's Drink! | Tue Mar 27 1990 13:46 | 7 |
| Indeed...that is the whole point. Xlib is supposed to be reentrant from async
callbacks. As someone said, there are a few bugs which will be fixed soon.
The TOOLKIT, however, is a different story. You can't call any Xt calls from
an AST/Signal.
Burns
|
| 2516.4 | A view from the field | SCAM::DIAL | | Tue Mar 27 1990 14:13 | 11 |
| I just completed two months of work porting an application to Xlib for
an OEM. This product depends on the ability to do Xlib calls from an
AST. From my experience with this customer's application, porting a
straight line application with AST driven keyboard input almost demands
the XSelectAsyncInput and Xlib calls from AST's features. Granted, it
would have been preferable to restructure the application to use the
toolkit, but this was not possible. As more customer applications are
converted to use DECwindows/X-windows, the impact of removing the
feature could be dramatic.
Barry
|
| 2516.5 | Major customer's ARE using this | SITBUL::MCCARTNEY | | Tue Mar 27 1990 17:01 | 8 |
| RE: .1
One of the major customers who required this (a rather large customer
in Texas, also a CMP), does make wide use of this feature. I'd hate to
see what happens if we tell them now that we're pulling support. They
may carry through with their initial threat of calling Sun.
Irene
|
| 2516.6 | Major portions of DECtp depend upon this working.... | IO::MCCARTNEY | James T. McCartney III - DTN 381-2244 ZK02-2/N24 | Tue Mar 27 1990 18:11 | 9 |
|
In fact, we are pushing for the tookit and Xlib to become THREAD-reentrant.
We can probably survive with just AST-reentrancy but it is an absolute
requirement that we be able to call Xlib from the AST. When CMA comes along
fully-reentrant code will become even more important.
James McCartney
DECforms Development
|
| 2516.7 | | KONING::KONING | NI1D @FN42eq | Wed Mar 28 1990 19:26 | 5 |
| I agree... every major software toolset needs to be thread-reentrant,
all the various pieces of DECwindows very much among them. ASTs will
have to do until threads show up.
paul
|