> Hi Roberto, > > On Tue, 26 Feb 2013 16:16:43 +0100 > Marcin Deranek <[email protected]> wrote: > >> On Tue, 26 Feb 2013 16:11:13 +0100 >> "Roberto De Ioris" <[email protected]> wrote: >> >> > so, i will make a bit more of research but it really looks like >> > ipcsem are the only way to make it (and that will explain why apache >> > is still using them albeit pretty old-fashioned) >> >> Looks like. Thank you Roberto. > > One more (hopefully last) question. When using ipcsem is see some of > these: > > # fgrep semop /var/log/uwsgi/error.log > Thu Mar 7 12:24:04 2013 - semop(): Interrupted system call [core/lock.c > line 482] > Thu Mar 7 12:26:36 2013 - semop(): Interrupted system call [core/lock.c > line 482] > Thu Mar 7 12:29:20 2013 - semop(): Interrupted system call [core/lock.c > line 482] > Thu Mar 7 12:31:51 2013 - semop(): Interrupted system call [core/lock.c > line 482] > Thu Mar 7 12:35:23 2013 - semop(): Interrupted system call [core/lock.c > line 482] > > These seem to be happening while worker is being cheaped (I'm using > busyness algo): > > Thu Mar 7 12:35:23 2013 - [busyness] 15s average busyness is at 28%, > cheap one of 13 running workers > Thu Mar 7 12:35:23 2013 - semop(): Interrupted system call [core/lock.c > line 482] > Thu Mar 7 12:35:24 2013 - uWSGI worker 4 cheaped. > > Is there anything to worry about ? > Regards, > >
That happens when a signal is sent to a worker blocked in semop(). I think it it safer to call semop() again on such situation (in your specific case it is not a problem as you are using locking only to reduce thundering herd, but could lead to corruption if you are locking for memory access) I will make a patch soon -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
