IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is infrastructure to improve our async r/w result handling and latency.
The pthreadpool signalling goes through a pipe. This has downsides: The main
event loop has to go through a read on the pipe before it can ship the result.
Also, it is not guaranteed by poll/epoll that the pthreadpool signal pipe is
handled with top priority. When an async pread/pwrite has finished, we should
immediately ship the result to the client, not waiting for anything else.
This patch enables tevent_immediate structs as job signalling. This means a
busy main tevent loop will handle the threaded job completion before any timed
or file descriptor events. Opposite to Jeremy's tevent_thread_proxy this is
done by a modification of the main event loop by looking at a linked list under
a central mutex.
Regarding performance: In a later commit I've created a test that does nothing
but fire one immediate over and over again. If you add a phread_mutex_lock and
unlock pair in the immediate handler, you lose roughly 25% of rounds per
second, so it is measurable. It is questionable that will be measurable in the
real world, but to counter concerns activation of immediates needs to go
through a new struct tevent_threaded_context. Only if such a
tevent_threaded_context exists for a tevent context, the main loop takes the
hit to look at the mutex'ed list of finished jobs.
This patch by design does not care about talloc hierarchies. The idea is that
the main thread owning the tevent context creates a chunk of memory and
prepares the tevent_immediate indication job completion. The main thread hands
the memory chunk together with the immediate as a job description over to a
helper thread. The helper thread does its job and upon completion calls
tevent_threaded_schedule_immediate with the already-prepared immediate. From
that point on memory ownership is again transferred to the main thread.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Such events were used before we had immediate events.
It's likely that there're a lot of this events
and we need to add new ones in fifo order.
The tricky part is that tevent_common_add_timer()
should not use the optimization as it's used
by broken Samba versions, which don't use
tevent_common_loop_timer_delay() in source3/lib/events.c.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This makes sure we don't preferr events which are at the beginning
of the list.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
When we're deciding what handlers to call in the select backend,
we didn't take into account the fact that the same fd may have
been added into the read FD_SET and the write FD_SET but with
different handlers.
We must match on both the file descriptor and the flags requested
before calling the handler.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
We might be called during tevent_re_initialise()
which means we need to free our old additional_data.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Set/get a single callback function to be invoked at various trace
points. Define "before wait" and "after wait" trace points - more
trace points can be added later if required.
CTDB wants this to log long waits and events.
Pair-programmed-with: Amitay Isaacs <amitay@gmail.com>
Signed-off-by: Martin Schwenke <martin@meltin.net>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
When doing
fd1 = tevent_add_fd(ev, ev, 2, 0, NULL, NULL);
fd2 = tevent_add_fd(ev, ev, 3, 0, NULL, NULL);
TALLOC_FREE(fd2);
fd2 = tevent_add_fd(ev, ev, 1, 0, NULL, NULL);
we end up with select_ev->maxfd==1. This is wrong.
An alternative fix might be to make select_ev->maxfd an unsigned int and make
EVENT_INVALID_MAXFD==UINT_MAX. But in theory we might end up with an fd of
UINT_MAX.
std_event_add_fd() contains exactly the same piece of code, so I'm directly
pushing it.
Volker
This makes the logic much simpler for the callers,
and matches the samba3 behavior.
If needed we can add performance tunning for tevent_loop_wait()
later.
metze
