http://www.perlmonks.org?node_id=1050248


in reply to [FCGI.pm] - not threads-safe?

FWIW, FCGI does show a threaded usage, but its the usage the OP is fighting :)

It did start off as fork based but they updated the API
http://search.cpan.org/grep?cpanid=FLORA&release=FCGI-0.74&string=thread&i=1&n=1&C=0
https://metacpan.org/source/FLORA/FCGI-0.74/threaded.PL
https://metacpan.org/source/FLORA/FCGI-0.74/os_win32.c ... CreateIoCompletionPort...

fastcgi threaded
->http://www.fastcgi.com/devkit/examples/threaded.c
->http://www.fastcgi.com/devkit/perl/threaded.PL

http://www.fastcgi.com/devkit/doc/www5-api-workshop.html

Tie-in to server architecture. API applications have to share the same architecture as the server: If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has single-threaded processes, multi-threaded applications don't gain any performance advantage. Also, when the server's architecture changes, the API will usually have to change, and applications will have to be adapted or rewritten.

...

3. Single-threaded and multi-threaded applications

FastCGI gives developers a free choice of whether to develop applications in a single-threaded or multi-threaded style. The FastCGI interface supports multi-threading in two ways:

Applications can accept concurrent Web server connections to provide concurrent requests to multiple application threads.

Applications can accept multiplexed Web server connections, in which concurrent requests are communicated over a single connection to multiple application threads.

Replies are listed 'Best First'.
Re^2: [FCGI.pm] - not threads-safe?
by BrowserUk (Patriarch) on Aug 20, 2013 at 21:29 UTC
    This:
    use Thread;

    is a dead duck since 5.8.0.

    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]

      use Thread; is a dead duck since 5.8.0.

      Yes, but https://metacpan.org/module/Thread Ricardo SIGNES / perl-5.18.1 / Thread says its been reworked using threads:: for old code

      The working pattern for the OP is following the same pattern., and the code uses perl_mutex

[reply]
        Thread says its been reworked using threads:: for old code

        Problem: Code designed to use Perl 5005threads isn't compatible with iThreads without considerable rework, if then.

        Monkey patching Thread to be an alias for threads in the vain and frankly naive hope that it would allow code written to use the former to magically work was ... well; naive at best. Thread should have been consigned to the dustbin of history along with pretty much everything in that namespace, excepting Thread::Queue which should have been moved into the threads namespace.

        So, the question is, does the presence of that single file in the FCGI distribution, that uses a long obsolete version of perl threading that never worked, and despite the fact that threading isn't mention in either the POD or the readme; and the only mention of threading in the C code is the use of a C thread to provide asynchronous IO for stdin; constitute a statement of support for the use of iThreads with FCGI?

        You know the answer to that as well as I do. Which makes your contribution in this thread one big red herring guaranteed to waste people's time.

        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]

In Section Seekers of Perl Wisdom