KOT MATPOCKuH wrote:
On Nov 22, 2007 9:01 PM, Timo Sirainen tss@iki.fi wrote:
I tried to make dovecot with configure --with-ioloop=select and same result: [skipped] pollsys(0xFFBFF888, 8, 0xFFBFF950, 0x00000000) = 1 pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000) = 0 pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000) = 0 pollsys(0xFFBFF888, 8, 0xFFBFF950, 0x00000000) = 1 pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000) = 0 pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000) = 0 [skipped to forever] and 100% of CPU time. Wonder why it still calls pollsys().. Does Solaris emulate select() using poll(), or did you somehow manage to get Dovecot configured with
On Thu, 2007-11-22 at 17:41 +0300, KOT MATPOCKuH wrote: poll after all? As I know, solaris emulate select() using poll()...
In Solaris 9 select() is implemented as a call to poll().
In Solaris 10 both select() and poll() are implemented as calls to pollsys().
On unpatched early release versions of Solaris 10 there was a problem if you called select() with a very short timeout (1us).
On Solaris 9 and other Unix systems this was rounded up to a 1ms timeout (or even higher - depending on the clock resolution of the system) and was implemented so that you slept/yielded *atleast* 1ms (if not more) if there wasn't any work to do (no file descriptors was ready).
On the first releases of Solaris 10 that was really translated into a 1us wait (since pollsys() supports really short timeouts and it also was checked against real wall clock. If this was executed on a slow machine and or a machine with many open file descriptors then chance was that pollsys() in itself might take more that 1us and this the syscall would never yield to another process if there was no file descriptors that needed work -> can you say busyloop...? :-)
I think this has been solved in a patch for Solaris 10 so that select() timeout values are always rounded up to 1ms to be backwards bug-compatible with broken code...
- Peter