glusterfs.git/libglusterfs/src/event.c, branch v7.1

event: rename event_XXX with gf_ prefixed

2019-08-21T06:13:38+00:00

I hit one crash issue when using the libgfapi.

In the libgfapi it will call glfs_poller() --> event_dispatch()
in file api/src/glfs.c:721, and the event_dispatch() is defined
by libgluster locally, the problem is the name of event_dispatch()
is the extremly the same with the one from libevent package form
the OS.

For example, if a executable program Foo, which will also use and
link the libevent and the libgfapi at the same time, I can hit the
crash, like:

kernel: glfs_glfspoll[68486]: segfault at 1c0 ip 00007fef006fd2b8 sp
00007feeeaffce30 error 4 in libevent-2.0.so.5.1.9[7fef006ed000+46000]

The link for Foo is:
lib_foo_LADD = -levent $(GFAPI_LIBS)
It will crash.

This is because the glfs_poller() is calling the event_dispatch() from
the libevent, not the libglsuter.

The gfapi link info :
GFAPI_LIBS = -lacl -lgfapi -lglusterfs -lgfrpc -lgfxdr -luuid

If I link Foo like:
lib_foo_LADD = $(GFAPI_LIBS) -levent
It will works well without any problem.

And if Foo call one private lib, such as handler_glfs.so, and the
handler_glfs.so will link the GFAPI_LIBS directly, while the Foo won't
and it will dlopen(handler_glfs.so), then the crash will be hit everytime.

The link info will be:
foo_LADD = -levent
libhandler_glfs_LIBADD = $(GFAPI_LIBS)

I can avoid the crash temporarily by linking the GFAPI_LIBS in Foo too like:
foo_LADD = $(GFAPI_LIBS) -levent
libhandler_glfs_LIBADD = $(GFAPI_LIBS)

But this is ugly since the Foo won't use any APIs from the GFAPI_LIBS.

And in some cases when the --as-needed link option is added(on many dists
it is added as default), then the crash is back again, the above workaround
won't work.

Backport of:
> https://review.gluster.org/#/c/glusterfs/+/23110/
> Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
> Fixes: #699
> Signed-off-by: Xiubo Li 

Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
updates: bz#1740519
Signed-off-by: Xiubo Li 
(cherry picked from commit 799edc73c3d4f694c365c6a7c27c9ab8eed5f260)

multiple files: another attempt to remove includes

2019-06-14T16:50:32+00:00

There are many include statements that are not needed.
A previous more ambitious attempt failed because of *BSD plafrom
(see https://review.gluster.org/#/c/glusterfs/+/21929/ )

Now trying a more conservative reduction.
It does not solve all circular deps that we have, but it
does reduce some of them. There is just too much to handle
reasonably (dht-common.h includes dht-lock.h which includes
dht-common.h ...), but it does reduce the overall number of lines
of include we need to look at in the future to understand and fix
the mess later one.

Change-Id: I550cd001bdefb8be0fe67632f783c0ef6bee3f9f
updates: bz#1193929
Signed-off-by: Yaniv Kaul

socket: socket event handlers now return void

2019-02-18T02:45:40+00:00

Problem:
Returning any value from socket event handlers to the event sub-system
doesn't make sense since event sub-system cannot handle socket
sub-system errors.

Solution:
Change return type of all socket event handlers to 'void'

Change-Id: I70dc2c57f12b7ea2fae41120f71aa0d7fe0b2b6f
Fixes: bz#1651246
Signed-off-by: Milind Changire

libglusterfs: Move devel headers under glusterfs directory

2018-12-05T21:47:04+00:00

libglusterfs devel package headers are referenced in code using
include semantics for a program, this while it works can be better
especially when dealing with out of tree xlator builds or in
general out of tree devel package usage.

Towards this, the following changes are done,
- moved all devel headers under a glusterfs directory
- Included these headers using system header notation <> in all
code outside of libglusterfs
- Included these headers using own program notation "" within
libglusterfs

This change although big, is just moving around the headers and
making it correct when including these headers from other sources.

This helps us correctly include libglusterfs includes without
namespace conflicts.

Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b
Updates: bz#1193929
Signed-off-by: ShyamsundarR

rpcsvc: provide each request handler thread its own queue

2018-11-29T01:19:12+00:00

A single global per program queue is contended by all request handler
threads and event threads. This can lead to high contention. So,
reduce the contention by providing each request handler thread its own
private queue.

Thanks to "Manoj Pillai" for the idea of pairing a
single queue with a fixed request-handler-thread and event-thread,
which brought down the performance regression due to overhead of
queuing significantly.

Thanks to "Xavi Hernandez" for discussion on
how to communicate the event-thread death to request-handler-thread.

Thanks to "Karan Sandha" for voluntarily running
the perf benchmarks to qualify that performance regression introduced
by ping-timer-fixes is fixed with this patch and patiently running
many iterations of regression tests while RCAing the issue.

Thanks to "Milind Changire" for patiently running
the many iterations of perf benchmarking tests while RCAing the
regression caused by ping-timer-expiry fixes.

Change-Id: I578c3fc67713f4234bd3abbec5d3fbba19059ea5
Fixes: bz#1644629
Signed-off-by: Raghavendra Gowdappa

event: get time by clock_gettime as pthread_cond_timedwait using

2018-09-17T13:42:45+00:00

Debug information shows time() has a delay between seconds increase,
get the right time by clock_gettime as pthread_cond_timedwait using.

                         ret = pthread_cond_timedwait (&event_pool->cond,
                                                       &event_pool->mutex,
                                                       &sleep_till);
+                         gf_msg ("epoll", GF_LOG_INFO, 0,
+                                 LG_MSG_EXITED_EPOLL_THREAD,
+                                 "pthread_cond_timedwait %lu %p return %d (active %d:%d)",
+                                 sleep_till.tv_sec, event_pool, ret,
+                                 event_pool->activethreadcount, threadcount);
                 }
         }
         pthread_mutex_unlock (&event_pool->mutex);

[2018-09-06 18:33:57.000879] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.000916] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.000931] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.000945] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.000957] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.000970] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.000983] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.000997] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.001010] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.001022] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.001034] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.001060] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230037 0x1f48e60 return 110 (active 5:4)
[2018-09-06 18:33:57.003085] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230038 0x1f48e60 return 0 (active 4:4)
[2018-09-06 18:33:57.014142] I [event.c:284:event_dispatch_destroy] 0-epoll: pthread_cond_timedwait 1536230038 0x1f48e60 return 0 (active 3:4)

Change-Id: I735249eee9a6f8284392b69e501479ac163b8409
fixes: bz#1626313
Signed-off-by: Kinglong Mee

Land part 2 of clang-format changes

2018-09-12T12:22:45+00:00

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu

coverity: libglusterfs issues

2018-08-19T10:03:52+00:00

CID: 1391415, 1274122, 1274201, 1382408, 1382437, 1389436
     1288798, 1288106, 1288110

updates: bz#789278
Change-Id: I48c7a50f22f5f4580310040c66463d9f7dd26204
Signed-off-by: Amar Tumballi

build: rename event.h to gf-event.h

2018-07-27T17:37:32+00:00

Newer FreeBSD versions (noticed with 10.3-RELEASE) provide a event.h
file that on occasion gets included instead of the libglusterfs file.
When this happens, 'struct event_pool' will not be defined and building
will fail with errors like:

    autoscale-threads.c:18:55: error: incomplete definition of type 'struct event_pool'
            int                      thread_count   = pool->eventthreadcount;
                                                      ~~~~^
    autoscale-threads.c:17:16: note: forward declaration of 'struct event_pool'
            struct event_pool       *pool           = ctx->event_pool;
                   ^

This problem is caused by 'pkg-config --cflags uuid' that adds
/usr/local/include to the GF_CPPFLAGS. The use of libuuid is preferred
so that the contrib/uuid/ directory can be removed.

By renaming event.h to gf-event.h there is no conflict between the
different event.h files anymore and compiling on FreeBSD works without
issues.

Change-Id: Ie69f6b8a4f8f8e9630d39a86693eb74674f0f763
Updates: bz#1607319
Signed-off-by: Niels de Vos

All: run codespell on the code and fix issues.

2018-07-22T14:40:16+00:00

Please review, it's not always just the comments that were fixed.
I've had to revert of course all calls to creat() that were changed
to create() ...

Only compile-tested!

Change-Id: I7d02e82d9766e272a7fd9cc68e51901d69e5aab5
updates: bz#1193929
Signed-off-by: Yaniv Kaul