2013-07-10 11:40:28 -07:00
|
|
|
/* Copyright (c) 2013 Nicira, Inc.
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at:
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
async-append: Refactor to avoid requiring enabling while single threaded.
Until now, the async append interface has required async_append_enable()
to be called while the process was still single-threaded, with the
rationale being that async_append_enable() could race with
async_append_write() on some existing async_append object. This was a
difficult problem when the async append interface was introduced, because
at the time Open vSwitch did not have any infrastructure for inter-thread
synchronization.
Now it is easy to solve, by introducing synchronization into the
async append module. However, that's more or less wasted, because the
client is already required to serialize access to async append objects.
Moreover, vlog, the only existing client, needs to serialize access for
other reasons, so it wouldn't even be possible to just drop the client's
synchronization.
This commit therefore takes another approach. It drops the
async_append_enable() interface entirely. Now any existing async_append
object is always enabled. The responsibility for "enabling", then, now
rests in whether the client creates and uses an async_append object, and
so vlog now takes care of that by itself. Also, since vlog now has to
deal with sometimes having an async_append and sometimes not having one,
we might as well allow creating an async_append to fail, thereby slightly
simplifying the "no async I/O" implementation from "write synchronously"
to "always fail creating an async_append".
Reported-by: Shih-Hao Li <shihli@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-02 17:32:25 -07:00
|
|
|
/* This is a null implementation of the asynchronous I/O interface for systems
|
|
|
|
* that don't have a form of asynchronous I/O. */
|
2013-07-10 11:40:28 -07:00
|
|
|
|
|
|
|
#include "async-append.h"
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
|
|
#include "util.h"
|
|
|
|
|
|
|
|
struct async_append *
|
async-append: Refactor to avoid requiring enabling while single threaded.
Until now, the async append interface has required async_append_enable()
to be called while the process was still single-threaded, with the
rationale being that async_append_enable() could race with
async_append_write() on some existing async_append object. This was a
difficult problem when the async append interface was introduced, because
at the time Open vSwitch did not have any infrastructure for inter-thread
synchronization.
Now it is easy to solve, by introducing synchronization into the
async append module. However, that's more or less wasted, because the
client is already required to serialize access to async append objects.
Moreover, vlog, the only existing client, needs to serialize access for
other reasons, so it wouldn't even be possible to just drop the client's
synchronization.
This commit therefore takes another approach. It drops the
async_append_enable() interface entirely. Now any existing async_append
object is always enabled. The responsibility for "enabling", then, now
rests in whether the client creates and uses an async_append object, and
so vlog now takes care of that by itself. Also, since vlog now has to
deal with sometimes having an async_append and sometimes not having one,
we might as well allow creating an async_append to fail, thereby slightly
simplifying the "no async I/O" implementation from "write synchronously"
to "always fail creating an async_append".
Reported-by: Shih-Hao Li <shihli@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-02 17:32:25 -07:00
|
|
|
async_append_create(int fd OVS_UNUSED)
|
2013-07-10 11:40:28 -07:00
|
|
|
{
|
async-append: Refactor to avoid requiring enabling while single threaded.
Until now, the async append interface has required async_append_enable()
to be called while the process was still single-threaded, with the
rationale being that async_append_enable() could race with
async_append_write() on some existing async_append object. This was a
difficult problem when the async append interface was introduced, because
at the time Open vSwitch did not have any infrastructure for inter-thread
synchronization.
Now it is easy to solve, by introducing synchronization into the
async append module. However, that's more or less wasted, because the
client is already required to serialize access to async append objects.
Moreover, vlog, the only existing client, needs to serialize access for
other reasons, so it wouldn't even be possible to just drop the client's
synchronization.
This commit therefore takes another approach. It drops the
async_append_enable() interface entirely. Now any existing async_append
object is always enabled. The responsibility for "enabling", then, now
rests in whether the client creates and uses an async_append object, and
so vlog now takes care of that by itself. Also, since vlog now has to
deal with sometimes having an async_append and sometimes not having one,
we might as well allow creating an async_append to fail, thereby slightly
simplifying the "no async I/O" implementation from "write synchronously"
to "always fail creating an async_append".
Reported-by: Shih-Hao Li <shihli@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-02 17:32:25 -07:00
|
|
|
return NULL;
|
2013-07-10 11:40:28 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
async_append_destroy(struct async_append *ap)
|
|
|
|
{
|
async-append: Refactor to avoid requiring enabling while single threaded.
Until now, the async append interface has required async_append_enable()
to be called while the process was still single-threaded, with the
rationale being that async_append_enable() could race with
async_append_write() on some existing async_append object. This was a
difficult problem when the async append interface was introduced, because
at the time Open vSwitch did not have any infrastructure for inter-thread
synchronization.
Now it is easy to solve, by introducing synchronization into the
async append module. However, that's more or less wasted, because the
client is already required to serialize access to async append objects.
Moreover, vlog, the only existing client, needs to serialize access for
other reasons, so it wouldn't even be possible to just drop the client's
synchronization.
This commit therefore takes another approach. It drops the
async_append_enable() interface entirely. Now any existing async_append
object is always enabled. The responsibility for "enabling", then, now
rests in whether the client creates and uses an async_append object, and
so vlog now takes care of that by itself. Also, since vlog now has to
deal with sometimes having an async_append and sometimes not having one,
we might as well allow creating an async_append to fail, thereby slightly
simplifying the "no async I/O" implementation from "write synchronously"
to "always fail creating an async_append".
Reported-by: Shih-Hao Li <shihli@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-02 17:32:25 -07:00
|
|
|
ovs_assert(ap == NULL);
|
2013-07-10 11:40:28 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
async-append: Refactor to avoid requiring enabling while single threaded.
Until now, the async append interface has required async_append_enable()
to be called while the process was still single-threaded, with the
rationale being that async_append_enable() could race with
async_append_write() on some existing async_append object. This was a
difficult problem when the async append interface was introduced, because
at the time Open vSwitch did not have any infrastructure for inter-thread
synchronization.
Now it is easy to solve, by introducing synchronization into the
async append module. However, that's more or less wasted, because the
client is already required to serialize access to async append objects.
Moreover, vlog, the only existing client, needs to serialize access for
other reasons, so it wouldn't even be possible to just drop the client's
synchronization.
This commit therefore takes another approach. It drops the
async_append_enable() interface entirely. Now any existing async_append
object is always enabled. The responsibility for "enabling", then, now
rests in whether the client creates and uses an async_append object, and
so vlog now takes care of that by itself. Also, since vlog now has to
deal with sometimes having an async_append and sometimes not having one,
we might as well allow creating an async_append to fail, thereby slightly
simplifying the "no async I/O" implementation from "write synchronously"
to "always fail creating an async_append".
Reported-by: Shih-Hao Li <shihli@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-02 17:32:25 -07:00
|
|
|
async_append_write(struct async_append *ap OVS_UNUSED,
|
|
|
|
const void *data OVS_UNUSED, size_t size OVS_UNUSED)
|
2013-07-10 11:40:28 -07:00
|
|
|
{
|
2013-12-17 10:32:12 -08:00
|
|
|
OVS_NOT_REACHED();
|
2013-07-10 11:40:28 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
async_append_flush(struct async_append *ap OVS_UNUSED)
|
|
|
|
{
|
2013-12-17 10:32:12 -08:00
|
|
|
OVS_NOT_REACHED();
|
2013-07-10 11:40:28 -07:00
|
|
|
}
|