On Sat, 06 Dec 2008 09:26:25 -0700
Neale Pickett <neale_AT_woozle.org> wrote:
> Jeremy Jay <dinkumator_AT_gmail.com> writes:
>
> > This was my hunch too, glad someone got it before me though. This
> > patch fixes the problem with 5.3. Probably the same with the
> > double- fork version too.
>
> The open FD was my first guess too, but the double-fork version didn't
> close any fds either, so I assumed it must be something else.
>
> Guillaume, if you apply the "close(0)" patch, does the problem go
> away?
>
> I'm away from my dwm computer right now, or I'd try it myself.
>
> Neale
>
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the "while | dwm" all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. But now, when I reinstall dwm-5.2 I
get the same problem than in dwm-5.3 and dwm-5.3.1, "double-fork",
"simple-fork" and re-"double-fork". I don't understand why.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a "spawn2" :
spawn2()
{
check for a certain shell script ".dwmstatus";
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(".dwmstatus");
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can change
the status when dwm is running and there are no more "quitting"
problem. This is just an idea, forgive me not to propose some real
code. Well tell me what you think of this idea.
-- Kind regards, Guillaume Quintin.Received on Sat Dec 06 2008 - 18:20:58 UTC
This archive was generated by hypermail 2.2.0 : Sat Dec 06 2008 - 18:24:04 UTC