Re: SoupServer - understanding multiple request at once handling

[Bernhard Schuster <schuster bernhard googlemail com>]

A callback will not help at all, if there exists a mixture of short and long operations. Long operations would still prevent handling secondary (short) requests, which could be served (almost) instantly.

So
soup_message_unpause (...)
soup_message_set_status (...)
soup_message_set_response (...)

are required to be the only ones modifing the session/message (which seems to work).

How is the below supposed to be implemented? According to the API doc (stable) everything is being processed in one and the same GMainContext, correct me if I am wrong.

Below the conceptual implementation with threads, which does contain potential races.

void

server_callback(...)
{

    //do some basic checks

    soup_server_pause_message (...);

    user_data... = ... //copy and ref all data which is required
    g_signal_conncet (msg, "finished", finished_callback_does_cleanup, user_data)

    g_thread_try_new("worker", threaded_worker, user_data, &error)

    g_assert (!error);

}

gpointer

threaded_worker (..., user_data)
{

    if (is_long_op(user_data))

        super_long_op(...);

    else

        short_op(...);

    soup_server_unpause_message (...);

    soup_message_set_status (...);

    soup_message_set_response (...);

    return NULL;

}

2013/8/18 Dan Winship <danw gnome org>

On 08/17/2013 04:16 PM, Bernhard Schuster wrote:
> The trick is to call `soup_message_pause`, put all info needed to
> process it further into a struct, pass that as `user_data` to a
> `GThread` or `pthread`, resume message processing in that thread by
> `soup_message_unpause`. Just recently did that, works like a charm.

You should not use a thread; SoupServer is not thread-safe. It's
designed to be used asynchronously if you want to be able to process
multiple signals at once; so rather than using another thread, use some
sort of callback from the GMainLoop.

-- Dan