Conference bulova::decw_jan-89_to_nov-90

The only restriction that DECwindows imposes on a multi-threaded client
application is that you can't do Xtoolkit or DWT calls from AST level.  If
you have code running at AST level that wishes to do toolkit calls, it can
put application-defined events on the X event queue to cause the mainline
code to do the window stuff.  Aside from that, there is no difference between
writing a DECwindows multi-thread application and writing any other sort of
multi-thread application.

--PSW

It sounds to me like you were talking more about Ada-style multi-threads; rather
than multiple active AST levels.  In this case, I think the main problem you
will find is that for now you can't call XTInitialize more than once per
real process.  Thus if you have multiple threads within a single process which
are creating separate display connections, etc, you will be in trouble, since
presumably each tk application will call XtInitialize.  This should be fixed
in VMS V5.2.

Burns

RE: .2

The problems with Ada-style multithreading and AST-based multithreading are
the same.  The stumbling block is that the toolkit isn't reentrant.  In an
Ada tasking environment, everything works just fine if you do all toolkit
calls from one task only.

--PSW

-  Are there any plans to make the toolkit reentrant?  

-  Is our X implementation itself reentrant?  (I know hardware resources like 
   color tables are a sore spot in attempting reentrancy...)

-  Are there any plans to make a major piece of the toolkit reentrant in a way 
   that would reduce in a meaningful way the amount of UI code that would have 
   to be serialized?  

I know reentrant coding is tougher to do, but it seems unfortunate that we are 
just coming out with systems with 2, 3, 4, ... processors and simultaneously 
coming out with software which isn't fully reentrant.  Fortunately, I don't 
think any of our competition have a fully reentrant implementation of X either,
so we're "safe", for now...

							Ralph

RE .2

�It sounds to me like you were talking more about Ada-style multi-threads; rather
�than multiple active AST levels.  In this case, I think the main problem you
�will find is that for now you can't call XTInitialize more than once per
�real process.  Thus if you have multiple threads within a single process which
�are creating separate display connections, etc, you will be in trouble, since
�presumably each tk application will call XtInitialize. 

This is exactly what I need: multiple display servers managed by the
same VMS process.  So I guess the answer to my original question is NO
since I can't call XtInitialize for each display server?  I need to use
it the same way ACMS will use DECforms; by calling the asynchronous
service which are reentrant.

� This should be fixed in VMS V5.2.

Does it means that the toolkit will be reentrant in VMS V5.2?

RE: .3

�The problems with Ada-style multithreading and AST-based multithreading are
�the same.  The stumbling block is that the toolkit isn't reentrant.  In an
�Ada tasking environment, everything works just fine if you do all toolkit
�calls from one task only.

I don't know if I understand this correctly.  To me, multi-threaded means
a single process dealing with many actions (usually many external devices
of the same type).  To do this, you usually need an AST like mechanism to
wake up the mainline that deals with a single thread at a time.  I don't 
know about ADA style multi-threading.  Sure the code must be reentrant
otherwise a thread will affect the next.

    You *can* control multiple displays from the same process using
    the current Xtoolkit:
    
    1) call XtToolkitInitialize() once;
    2) call XtCreateApplicationContext() once;
    3) call XtOpenDisplay(...) any number of times;
    4) call XtAppCreateShell(...) for each display;
    5) build widget hierarchy for each display;
    6) call XtRealizeWidget(...) for each display's top-level (shell)
       widget;
    7) call XtAppMainLoop() once;
    8) enjoy.
    
    For a simple example of this, see tbd1::decw$ll:chess.*,build_chess.com
    
    Dave

> � This should be fixed in VMS V5.2.
>
> Does it means that the toolkit will be reentrant in VMS V5.2?

No.  It means you should be able to call XtInitialize more than once
in VMS V5.2.

Leo

I think I confused things more than I helped.  Yes the toolkit is not reentrant.
Critical sections are not protected against ASTs.  If the threads requested in
.0 are switched by an AST, then it won't work even in 5.2.

However, starting in 5.2, you will be able to have multiple independent sections
of code each of which call XtInitialize and play along merrily as though there
is no other connection in that process.  The issue is synchronizing the threads.

Currently Xlib is usable at both USER and USER AST levels.  In that sense it is
reentrant.

The reason for this problem, of course, is that the tk intrinsics development
was done initially on Unix, where ASTs and the like are not a concern.  Jim
Gettys was kind enough to protect critical sections in Xlib with lock and unlock
macros which we filled in with OS-dependent stuff to prevent ASTs from happening
in these sections.  I don't know if such things exist in the toolkit or not.
If not, making them reentrant will be a lot harder.

Burns

When can we expect to see full rentrancy in the toolkit?

James