Conference bulova::decw_jan-89_to_nov-90

	No, but you can call Xlib routines from AST level. The best
	workaround for this situation (at least, it's what we do) is
	to use XSendMessage to send yourself a client event, which will
	be received and handled outside of AST level.

	Mike

Got it. Thanks!

John

Or if possible, have your ASTs triggered by event flags instead.
The XtAppAddInput routine will accept an EFN and IOSB to trigger
off of...

Even when we couldn't supply an EFN in some cases - in our AST
routine we set the EF ourselves.

    Setting an event flag will be much more efficient that doing a
    SendEvent.

Setting WHICH event flag?  The documentation doesn't make clear which EF
DECwindows uses.  All I know for sure is that you can't use any of the ones
returned by LIB$GET_EF, which strikes me as pretty poor design for something
that's supposed to fit in the VMS modular programming environment.

--PSW

    
    re .5:  Now, now, now... Actually, it's the VMS event flag conventions
    that don't fit in the VMS modular programming environment.  Xlib needed
    an event flag for it's operations and being DIGITAL supplied, it could
    only use DIGITAL-reserved event flags.  These happen to be in ef
    cluster 0 which just happens to be exactly the cluster which isn't used
    in allocating event flags by the *typical* use of lib$get_ef.  (It just
    so happens that I was using ef cluster 1 for awhile for just this
    reason but was told "nonono".)

RE: .6

What we really need is a $WAITM service that will wait across multiple EFCs.

--PSW

    
    If you throw in the capability of optionally using IOSB's with the
    EFC's I'll gladly join the cause.

Most layered product that I known of (Digital-supplied of course) use GET_EF 
to get their EFNs - and SQM doesn't balk. If GET_EF is a no-no, then who saying
that?

James

P.S. I'd settle for a "X$GET_EFN" hack!

    
    re: .5 & .6
    
    So, is it safe to LIB$FREE_EF an event flag out of cluster 0 (doc says 1
    thru 23 are initially reserved but may be freed), and then
    LIB$RESERVE_EF that flag for use with XtAppAddInput?
    
    Does the 'condtion' arg to XtAppAddInput HAVE to be an IOSB, or can I
    safely use an $ENQ lock status block?
    

    re .10:
    
    You certainly may lib$free_ef those event flags.  I believe the default
    behaviour of lib$get_ef was chosen as a reasonable response to previous
    bad programming practices.
    
    						m

Wether or not the EFN-management routines are well-behaved VMS modular
routines, if *DECwindows* was well-behaved, this would not be an issue because
you would be able to call it at AST level in the first place.

    re .11:
    
>    You certainly may lib$free_ef those event flags.  I believe the default
>    behaviour of lib$get_ef was chosen as a reasonable response to previous
>    bad programming practices.
 
Just to double check, this *is* safe, right?

In other words, is it possible that DECwindows has already done a
lib$reserve_ef on a cluster 0 flag *from my process context* so that
when I lib$free_ef it works thinking I'm done with that flag when
in reality DECwindows is still using it (or we are both using it :-( ) ?

Is the following code "safe":


/*
 * Allocate a cluster 0 EFNs for XtApplAddInput() and the PPL stuff in
 * ITECS_DEV
 */
efnok=0;
for(UpdateDisplayEFN = 1 ; UpdateDisplayEFN < 32 ; UpdateDisplayEFN++) {
   if(lib$free_ef(&UpdateDisplayEFN) != SS$_NORMAL) continue;
   if(lib$reserve_ef(&UpdateDisplayEFN) != SS$_NORMAL) break;
   efnok = 1;
   break;
};
if(!efnok) {
   printf("Can't get a cluster 0 EFN for XtAppAddInput!\n");
   I_CleanUpAndExit();
};

re .14:  It *may* be safe.  If some other part of the application, such as a
library, attempts to allocate event flags with a similar algorithm you'll
both end up using the same event flag which may cause a problem.  (Also,
you should restrict the free_ef loop to event flags 1 to 23.)  Another
approach is to free event flags 1 to 23 early in application startup and
then whenever the application needs an event flag, it loops trying to
reserve one in this range.  However, if some part uses the old lib$get_ef
procedure, it may be surprised to find that it received an event flag
in ef cluster 0.  You really need to know how every event flag user in
the application works.

						monty

> RE: .6
>
> What we really need is a $WAITM service that will wait across multiple EFCs.
> 
> --PSW

What really need is a higher level of abstraction than the MACRO like VMS
System Services going back to the PDP days. The EVENT type in VAXeln is a
much better concept.

VAR
    event1, event2;

BEGIN
    CLEAR_EVENT (event1);
    CLEAR_EVENT (event2);
    ...


    SIGNAL_EVENT (event2);

    ...

    WAIT_ANY (event1, event2);

This is a lot nicer than VMS event flags!

Olav

re .15:

I think I'm safe. All cluster 0 flags get allocated at init time (changed 
now to limit the search to 1-23).

Thanks,
John

    re .16:  Except isn't it true that eln's WAIT_ANY service can only take
    four events?  What we really need is post-4.3 bsd's select() with a
    single I/O handle and built on sysV's semaphores (after fixing).

Re: .18

VAXELN is implementing a new form of WAIT_ANY/ALL that takes an
arbitrarily long list of objects to wait for.

I also agree that allocatable events are the way to go, but LIB$GET_EF
solves this problem for MOST applications.  Besides, philosophizing on
how certain fundamental design decisions for VMS should have been
made differently is not very useful.

				Steve

    
>Besides, philosophizing on
>how certain fundamental design decisions for VMS should have been
>made differently is not very useful.
    
    Ah, yes, but being a critic is fun.  You know, "the cost of everything
    and the value of nothing."

Besides which, there isn't any reason why VMS couldn't implement real semaphores
in addition to event flags.  After all, it uses them extensively internally
(that is what mutexes are).

The main reason for the existence of event flags is so that one can swap
process address space and not have to worry about posting and testing flags in
the now swapped-out address space.  The restrictions on the number of event
flags and on their association are to keep the process control block size small,
and to conserve non-paged pool.  These were more important considerations when
there were VAXes with only 256K real memory.

--PSW