Re: xterm_title patch 898

[Tribhuvan <loka rcn com>]

I was thinking of a solution for the time-out/delay problem...
Outside of the choice of method used to get and set the xterm
title, there still remains the possibility of failure or
delay under certain conditions while storing the old_xterm_title..

Thus the SIGALRM was introduced to allow for this descrepancy,
being that it is more desireable to have the alarm cause a
SIGINT and exit the process (eliminating the possibility of
a restore) rather than dump garbage to stdout (the cmd line
in this case). However, as noted in some respect by all, there
seems as yet no way to cancel the alarm once it has been set,
should the old_title be stored before the alarm() has awaken.
I was thinking of an alternative approach to the straight
signalling as in the current patch.

The model uses threading.
If two child threads were called from the store_xterm_title
function, one having a simple sleep() call and the other
reading the old_xterm_title - each of these childs could be
contained in a while loop, checking on a common flag. Once
the flag is reset by the first thread which has reached it's
goal, it causes the other to exit also, and the caller may
then return the title array and exit.
(below is not exactly code but a hint at coding):

int continue = 1;

child_1:
while (continue)
{sleep(5)}
continue=0
thr_exit()

child_2:
while(continue)
{...read and store xterm title ...}
continue=0
thr_exit()


I don't know if the exact model above is possible, but
the basic concept of two child threads each with the
ability to cause SIGINT to the caller, which subsequently
kills the remaining child thread and exits. The first
child to attain the goal causes all others to exit. Thus
if old_xterm_title is stored within a fraction of a second,
we don't wait around. Under networked environment we take as
long as is needed to safetly store title - within a timeout
threshold.
I've been working on such a model but I need a little more
time to get the exit/kill-child process right. Otherwise
everything else works so far. Actually, the model I'm working
on does not have the common variable but attemps to return a
signal to the caller on completion, and the caller subsequently
kills remaining child process and then exit with a
'return title+3;'.

btw. is there objection to using posix threads if the model
actually works?

Tribhuvan