in reply to Re^8: Help designing a threaded service
in thread Help designing a threaded service

The reason is to not waste CPU, not to avoid accepting the same connection in different workers, which won't happen even if you disable this option.

Hm. I don't how you draw that conclusion from the docs you linked.

This, "If accept_mutex is enabled, worker processes will accept new connections by turn. Otherwise, all worker processes will be notified about new connections, " very clearly states pretty much the opposite.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^9: Help designing a threaded service

Replies are listed 'Best First'.
Re^10: Help designing a threaded service
by Anonymous Monk on Jan 28, 2014 at 01:22 UTC
    There's a difference between being notified about new connection and accepting it.
[reply]
      There's a difference between being notified about new connection and accepting it.

      OKay. So all of these identical workers are sitting polling, poll/epoll/select/whatever, and when a new client connects, exactly one of them will come out of the polling with a new client socket in a can read state, and all the others will get a polite note slipped under their doors informing them of the event.

      Do please think before pedanting.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        come out of the polling with a new client socket in a can read state
        nonsense. They all (or just some of them) come out of the polling with the listening socket in can read state. Poll/epoll/select don't return any new sockets, for that workers have to call accept, which will return connection only to one worker. 
        use 5.010;
use strict;
use warnings;

use IO::Socket::INET;
use IO::Poll;
use Time::HiRes;

my $port = shift // 7777;
my $sock = IO::Socket::INET->new(LocalPort => $port, Listen => 10);
$sock->blocking(0);

for ( 1 .. 3 ) {
    my $pid = fork;
    unless ($pid) {
        my $poll = IO::Poll->new;
        $poll->mask( $sock => POLLIN );
        while ( $poll->poll >= 0 ) {
            say "$$ got out of poll";
            my $cli = $sock->accept;
            if ($cli) {
                say "$$ accepted connection from " . $cli->peerport;
                print while <$cli>;
                exit 0;
            }
            else {
                say "$$ got nothing from accept";
            }
        }
    }
}
__END__
4367 got out of poll
4367 accepted connection from 58442
4365 got out of poll
4366 got out of poll
4366 got nothing from accept
4365 accepted connection from 58446

        [download]
        As you can see when there's an incoming connection, poll may return in several workers, but only one worker can accept the connection.
[reply]
[d/l]

In Section Seekers of Perl Wisdom