summaryrefslogtreecommitdiffstats
path: root/libglusterfs/src/syncop.c
Commit message (Collapse)AuthorAgeFilesLines
* Change Copyright current yearPranith Kumar K2011-08-101-1/+1
| | | | | | | | Change-Id: Ia85fa5617fb0bb438dbe3660d36465c0ecb000be BUG: 3348 Reviewed-on: http://review.gluster.com/199 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@gluster.com>
* LICENSE: s/GNU Affero General Public/GNU General Public/v3.1.6qa6Pranith Kumar K2011-08-061-3/+3
| | | | | | | | Change-Id: I30b1807f4493a9b4ffa9899548daf7d29a0a6364 BUG: 3348 Reviewed-on: http://review.gluster.com/184 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@gluster.com>
* Change GNU GPL to GNU AGPLPranith K2010-10-041-3/+3
| | | | | | | | Signed-off-by: Pranith Kumar K <pranithk@gluster.com> Signed-off-by: Vijay Bellur <vijay@dev.gluster.com> BUG: 1388 () URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1388
* add pump xlator and changes for replace-brickPavan Sondur2010-08-061-1/+191
| | | | | | | | Signed-off-by: Pavan Vilas Sondur <pavan@gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 1235 (Bug for all pump/migrate commits) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1235
* syncop: initial implementationPavan Sondur2010-07-281-0/+350
Resending Avati's syncop patch with a few bug fixes. (please do not skip the IMPORTANT NOTES section) * Framework for SYNChronous OPerations -------------------------------------- This patch provides a framework for performing synchronous operations over the underlying actual asynchronous GlusterFS FOPS. * Use cases ----------- 1. Convenient implementation of crawler thread in replicate/pump 2. Convenient implementation of high level control flow in DVM * Background ------------ All (almost) threads in GlusterFS are hosts for executing aysnchronous file operations using the STACK_WIND and STACK_UNWIND primitives - as calls and callbacks. While the STACK_WIND and STACK_UNWIND macros provide high control for efficiently implementing file operations in a clustered/parallel environment, there are tasks where the nature of the task itself is sequential and the execution performance of the task is not critical. In these cases the complexity to implement the task with STACK_WIND/STACK_UNWIND based operations as calls and callbacks is an overkill. * Introduction --------------- syncop: are wrappers around the STACK_WIND/STACK_UNWIND based asynchronous fops. synctask: a sequential task (a C function) which uses syncops. syncenv: an environement to schedule and execute synctasks. The synchronicity is implemented via ucontext.h based continuations. Execution of synchronous tasks is possible only in a synchronous environment. Therefore, the first step is to create such an environment - struct syncenv *env = syncenv_new (0); This creates a synchronous environment, with a thread (scheduler) to host the synchronous tasks. Creation of this environment is generally to be done at the time of process initialization. Next is to spawn a synchronous task in this environment - int slow_self_heal (void *data); int completion_func (int ret, void *data); ret = synctask_new (env, slow_self_heal, completion_func, data); Here slow_self_heal is a task which is implemented using synchronous operations. When slow_self_heal() completes, completion_func() is called with the first parameter as the return value of slow_self_heal(). Both these functions get the @data argument as the same value passed to synctask_new(). int slow_self_heal (void *data) { xlator_t *child = FIRST_CHILD (THIS); fd_t *dir = NULL; ... dir = syncop_opendir (child, loc); entry = syncop_readdir (dir); ... return ret; } * IMPORTANT NOTES ----------------- - calling syncops in code executing outside the synchronous environment will very likely cause and undesired blocking of the executing thread leading to deadlocks!! The synchronous environment is a special thread where such sleeps are safe, and these sleeps result in the scheduler to 'swap in' other synctasks. - syncops can put the task to sleep. DO NOT issue syncops while holding mutexes. This is very similar to the blunder of holding a mutex and doing STACK_WIND. - It works best when synctasks use only syncops. If a call_frame is created and STACK_WIND'ed, the callback would very likely happen in a thread outside the synchronous enviroment, at an undefined time - as expected. So note that the synchronous environment does not tame the notorious behaviour of STACK_WIND. Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 971 (dynamic volume management) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=971