>>>>> "JS" == Julian Stecklina <[EMAIL PROTECTED]> writes:
JS> Milan Zamazal <[EMAIL PROTECTED]> writes:
>> The only remaining problem is that if using run-shell-command in
>> the timers then StumpWM hangs about once or twice per day, with
>> both the threaded and non-threaded SBCL versions. No error
>> message, no backtrace, no way to handle windows and SBCL has to
>> be killed from another terminal. Well, the obvious work around
>> is not to use run-shell-command which is possible in most cases.
JS> Could you post this to the SBCL people? Perhaps you can build a
JS> minimal example outside of stumpwm. I guess, it would be quite
JS> helpful in solving this problem.
I'll try when I have some time...
>>>>> "VM" == Vitaly Mayatskikh <[EMAIL PROTECTED]> writes:
VM> I thought it was fixed in 1.0.16:
VM> * bug fix: copying output from RUN-PROGRAM to a stream
VM> signalled bogus errors if select() was interrupted.
The problem I describe above happens with SBCL 1.0.16 (from Debian).
>>>>> "SB" == Shawn Betts <[EMAIL PROTECTED]> writes:
SB> It's moot now but I want to point out that multiple timers isn't
SB> exactly the source of the issue. stumpwm figures out when the
SB> next timeout is due and uses clx's event timeout to schedule a
SB> wake up at that time. It then does what needs to be done (clear
SB> the message bar, update modeline, etc) and then figures out when
SB> the next timeout is due. and so on. I felt labeling this as
SB> "multiple timers" was misleading.
I see. Good to know.
Regards,
Milan Zamazal
_______________________________________________
Stumpwm-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/stumpwm-devel
