RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2025-01-25 23:12:54 +00:00
Code Issues Packages Projects Releases Wiki Activity
b882dd88cc
haproxy/src/applet.c

55 lines
1.5 KiB
C
Raw Normal View History

MEDIUM: applet: add basic support for an applet run queue This will be needed so that we can schedule applets out of the streams. For now nothing calls the queue yet.
2015-04-13 15:11:11 +00:00
/*
* Functions managing applets
*
* Copyright 2000-2015 Willy Tarreau <w@1wt.eu>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <common/config.h>
#include <common/mini-clist.h>
#include <proto/applet.h>
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
#include <proto/channel.h>
MEDIUM: applet: implement a run queue for active appctx The new function is called for each round of polling in order to call any active appctx. For now we pick the stream interface from the appctx's owner. At the moment there's no appctx queued yet, but we have everything needed to queue them and remove them.
2015-04-19 07:59:31 +00:00
#include <proto/stream.h>
#include <proto/stream_interface.h>
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
#include <proto/task.h>
MEDIUM: applet: add basic support for an applet run queue This will be needed so that we can schedule applets out of the streams. For now nothing calls the queue yet.
2015-04-13 15:11:11 +00:00
MINOR: applet: Count number of (active) applets As for tasks, 2 counters has been added to track : * the total number of applets : nb_applets * the number of active applets : applets_active_queue [wt: needed for next fixes, to backport to 1.7 and 1.6]
2016-12-06 08:13:22 +00:00
unsigned int nb_applets = 0;
MAJOR: threads/applet: Handle multithreading for applets A global lock has been added to protect accesses to the list of active applets. A process mask has also been added on each applet. Like for FDs and tasks, it is used to know which threads are allowed to process an applet. Because applets are, most of time, linked to a session, it should be sticky on the same thread. But in all cases, it is the responsibility of the applet handler to lock what have to be protected in the applet context.
2017-06-19 10:38:55 +00:00
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
struct task *task_run_applet(struct task *t, void *context, unsigned short state)
MEDIUM: applet: implement a run queue for active appctx The new function is called for each round of polling in order to call any active appctx. For now we pick the stream interface from the appctx's owner. At the moment there's no appctx queued yet, but we have everything needed to queue them and remove them.
2015-04-19 07:59:31 +00:00
{
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
struct appctx *app = context;
struct stream_interface *si = app->owner;
MEDIUM: applet: implement a run queue for active appctx The new function is called for each round of polling in order to call any active appctx. For now we pick the stream interface from the appctx's owner. At the moment there's no appctx queued yet, but we have everything needed to queue them and remove them.
2015-04-19 07:59:31 +00:00
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
if (app->state & APPLET_WANT_DIE) {
__appctx_free(app);
return NULL;
MAJOR: applet: applet scheduler rework. In order to authorize call of appctx_wakeup on running task: - from within the task handler itself. - in futur, from another thread. The appctx is considered paused as default after running the handler. The handler should explicitly call appctx_wakeup to be re-called. When the appctx_free is called on a running handler. The real free is postponed at the end of the handler process.
2017-06-26 14:36:53 +00:00
}
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
/* Now we'll try to allocate the input buffer. We wake up the
* applet in all cases. So this is the applet responsibility to
* check if this buffer was allocated or not. This let a chance
* for applets to do some other processing if needed. */
MEDIUM: stream-int: replace channel_alloc_buffer() with si_alloc_ibuf() everywhere Well that's only 3 places (applet.c, stream_interface.c, hlua.c). This ensures we always clear SI_FL_WAIT_ROOM before setting it on failure, so that it is granted that SI_FL_WAIT_ROOM always indicates a lack of room for doing an operation, including the inability to allocate a buffer for this.
2018-10-25 08:21:41 +00:00
if (!si_alloc_ibuf(si, &app->buffer_wait))
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
si_applet_cant_put(si);
/* We always pretend the applet can't get and doesn't want to
* put, it's up to it to change this if needed. This ensures
* that one applet which ignores any event will not spin.
BUG/MAJOR: applet: use a separate run queue to maintain list integrity If an applet wakes up and causes the next one to sleep, the active list is corrupted and cannot be scanned anymore, as the process then loops over the next element. In order to avoid this problem, we move the active applet list to a run queue and reinit the active list. Only the first element of this queue is checked, and if the element is not removed, it is removed and requeued into the active list. Since we're using a distinct list, if an applet wants to requeue another applet into the active list, it properly gets added to the active list and not to the run queue. This stops the infinite loop issue that could be caused with Lua applets, and in any future configuration where two applets could be attached together.
2015-09-25 15:56:16 +00:00
*/
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
si_applet_cant_get(si);
si_applet_stop_put(si);
MEDIUM: applet: implement a run queue for active appctx The new function is called for each round of polling in order to call any active appctx. For now we pick the stream interface from the appctx's owner. At the moment there's no appctx queued yet, but we have everything needed to queue them and remove them.
2015-04-19 07:59:31 +00:00
MAJOR: applets: Use tasks, instead of rolling our own scheduler. There's no real reason to have a specific scheduler for applets anymore, so nuke it and just use tasks. This comes with some benefits, the first one being that applets cannot induce high latencies anymore since they share nice values with other tasks. Later it will be possible to configure the applets' nice value. The second benefit is that the applet scheduler was not very thread-friendly, having a big lock around it in prevision of this change. Thus applet-intensive workloads should now scale much better with threads. Some more improvement is possible now : some applets also use a task to handle timers and timeouts. These ones could now be simplified to use only one task.
2018-05-25 14:58:52 +00:00
app->applet->fct(app);
si_applet_wake_cb(si);
channel_release_buffer(si_ic(si), &app->buffer_wait);
return t;
MEDIUM: applet: implement a run queue for active appctx The new function is called for each round of polling in order to call any active appctx. For now we pick the stream interface from the appctx's owner. At the moment there's no appctx queued yet, but we have everything needed to queue them and remove them.
2015-04-19 07:59:31 +00:00
}
MAJOR: threads/applet: Handle multithreading for applets A global lock has been added to protect accesses to the list of active applets. A process mask has also been added on each applet. Like for FDs and tasks, it is used to know which threads are allowed to process an applet. Because applets are, most of time, linked to a session, it should be sticky on the same thread. But in all cases, it is the responsibility of the applet handler to lock what have to be protected in the applet context.
2017-06-19 10:38:55 +00:00
Reference in New Issue Copy Permalink