Messages in this thread | | | Date | Tue, 26 Aug 2003 01:00:44 +0200 | From | Alex Riesen <> | Subject | Re: [PATCH]O18.1int |
| |
Con Kolivas, Tue, Aug 26, 2003 00:48:23 +0200: > > Afaics, the application (rxvt) just sleeps at the beginning waiting for > > input from X. As every terminal would do. At some point its inferior > > process finishes, but it fails to notice this spinning madly in the > > internal loop calling select, which returns immediately (because other > > side of pty was closed. That is the error in rxvt). Probably it has > > accumulated enough "priority" up to this moment to block other > > applications (window manager, for example) when it suddenly starts running? > > Something like that. Interesting you point out select as wli was > profiling/tracing the mozilla/acroread plugin combination that spins on wait > and also found select was causing grief. It was calling select with a 15ms > timeout and X was getting less than 5ms to do it's work and respond and it > was repeatedly timing out. Seems a common link there. >
Yes, looks similar. Probably a simplier test could be to let the program loop using select on stdin with zero timeout (it is a pty usually :)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |