| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
I have a question regarding the sequencing of work procs. Are work procs processed in LIFO or FIFO fashion? The DECWIndows Programming Manual (V1 docset, which is all I have available) in volume 1B, page 2-44 states that "... the most recently added procedure is always the one that is called." This implies LIFO behaviour. One of the responses in note 544 states the same thing. However my application appears to be running them FIFO. I have a work proc (WP1) reading a script file and dispatching a command read from each line of the file. It handles one line per work proc call. A certain command (called LOAD) starts another work proc (WP2). With LIFO behaviour, which is what I want, the WP1 should block until WP2 has finished. This is required by the application since commands ocurring after the LOAD may depend on the load being finished. Here's was the test script: LOAD <filename> GET <object> GET <object> GRAPH The sequnce of events on the screen would lead me to believe that the command were executed as: GET GET GRAPH LOAD Reading the journal record showed that the two GETs returned "No file" errors. Could there be some sort of "start up time" required between when WP1 does the XtAddWorkProc() and when WP2 finally does get called by the event handler, with WP1 called a few times in between? I have a hard time believing this could happen. Enlightment on the subject would be appreciated. - norm
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3316.1 | << Simple Test Case >> | WONDER::COMMO | I'll find no bug before its time! | Fri Sep 07 1990 12:24 | 124 |
A further, simple experiment seems to prove FIFO. Perhaps there are some
subtle things happening that I don't appreciate or perhaps the meaning of LIFO
and FIFO are opposite from what I understood.
I will list the results first and then the code.
Actual Results (LIFO) Expected Results (FIFO)
---------------------------------------------------------------
WP1, part 1: pass 4 WP1, part 1: pass 4
WP1, part 1: pass 3 WP1, part 1: pass 3
WP1, part 1: pass 2 WP1, part 1: pass 2
WP1, part 1: pass 1 WP1, part 1: pass 1
WP1, part 2: pass 5 WP2, part 1: pass 3
WP1, part 2: pass 4 WP2, part 1: pass 2
WP1, part 2: pass 3 WP2, part 1: pass 1
WP1, part 2: pass 2 WP3: pass 3
WP1, part 2: pass 1 WP3, pass 2
WP2, part 1: pass 3 WP3, pass 1
WP2, part 1: pass 2 WP2, part 2: pass 3
WP2, part 1: pass 1 WP2, part 2: pass 2
WP2, part 2: pass 3 WP2, part 2: pass 1
WP2, part 2: pass 2 WP1, part 2: pass 5
WP2, part 2: pass 1 WP1, part 2: pass 4
WP3: pass 3 WP1: part 2: pass 3
WP3: pass 2 WP1: part 2: pass 2
WP3: pass 1 WP1: part 2: pass 1
/****
*****
***** Test functions
*****
****/
typedef struct {
int tcnt;
int tmax;
int tflag;
} TS;
static Boolean wp3(TS *sP)
{
while (sP->tcnt)
{
printf(" WP3: pass %d\n",sP->tcnt--);
return 0;
}
XtFree(sP);
return 1;
}
static Boolean wp2(TS *sP)
{
TS *sP2;
while (sP->tcnt)
{
printf(" WP2, part %d: pass %d\n",1+sP->tflag,sP->tcnt--);
return 0;
}
if (!sP->tflag)
{
sP->tcnt = sP->tmax;
sP->tflag = TRUE;
sP2 = XtMalloc(sizeof(TS));
sP2->tmax = sP2->tcnt = 3;
sP2->tflag = 0;
XtAddWorkProc(wp3,sP2);
return 0;
}
XtFree(sP);
return 1;
}
static Boolean wp1(TS *sP)
{
TS *sP2;
while (sP->tcnt)
{
printf("WP1, part %d: pass %d\n",1+sP->tflag,sP->tcnt--);
return 0;
}
if (!sP->tflag)
{
sP->tcnt = sP->tmax;
sP->tflag = TRUE;
sP2 = XtMalloc(sizeof(TS));
sP2->tmax = sP2->tcnt = 3;
sP2->tflag = 0;
XtAddWorkProc(wp2,sP2);
return 0;
}
XtFree(sP);
return 1;
}
/*
** this is the top level function, started from a main
** event loop callback.
*/
static char *test(char *s)
{
TS *sP;
sP = XtMalloc(sizeof(TS));
sP->tmax = sP->tcnt = abs(atoi(s));
sP->tflag = 0;
XtAddWorkProc(wp1, sP);
return NULL;
}
| |||||
| 3316.2 | Intrinsics spec is more complete... | LEOVAX::TREGGIARI | Fri Sep 07 1990 13:27 | 11 | |
The R3 and R4 Intrinsics spec say: "Multiple work procedures can be registered, and the most recently added one is always the one that is called. However, if a work procedure adds another work procedure, the newly added one has a lower priority than the current one." This is probably a clarification that was added after our documentation was written, and that's why it's not in there. Leo | |||||
| 3316.3 | << Ah, peace in the valley again >> | WONDER::COMMO | I'll find no bug before its time! | Fri Sep 07 1990 13:43 | 12 |
>This is probably a clarification that was added after our documentation >was written, and that's why it's not in there. Thanks, Leo. It lloks like I can fend off the men in the white lab coats yet one more time. I appreciate your clarification. I have a solution to my problem in hand. Not elegant, but easy and effective. - norm | |||||
| 3316.4 | See the other work proc | TOOLEY::B_WACKER | Mon Sep 10 1990 11:23 | 1 | |
It is documented under AppAddWorkProc, just not under AddWorkProc. | |||||