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 will be the core of the non-blocking lock idea for ctdb, it will be used
in place of ctdb_ltdb_fetch(), but will also get a lock. It re-starts a request
if it needs to block
(This used to be ctdb commit afa479026cf6293e6a878c8a329cdac035284672)
The problem we have is this:
- we want the client smbd processes to be able to 'shortcut' access
to the ltdb, by directly accessing the ltdb, and if the header of
the record shows we are the dmaster then process immediately, with
no overhead of talking across the unix domain socket
- a client doing a shortcut will use tdb_chainlock() to lock the
record while processing
- we want the main ctdb daemon to be able to set locks on the
record, and when those locks collide with a 'shortcut' fcntl lock,
we want the ctdb daemon to keep processing other operations
- we don't want to have to send a message from a smbd client to the
ctdbd each time it releases a lock
The solution is shown in this example. Note that the expensive fork()
and blocking lock is only paid in case of contention, so in the median
case I think this is zero cost.
(This used to be ctdb commit a3248c3e2b740cd2403acffd3c1f6a33dca0ea03)
- when we do a store_unlock the lock record becomes unlocked, so we
must destroy it (or we leak memory)
(This used to be ctdb commit d85955640e670dd580073da96b25fb8a10c08d18)
this makes it possible to do fetch_lock and store_unlock across a domain socket to read/write data.
note that the actual locking is NOT implemented yet
(This used to be ctdb commit c7a397c56caf71283c081e5b97620085ed5108c6)
note that the store_unlock does not actually do anything yet apart from passing the pdu from client to daemon and daemon responds.
next is to make sure the daemon actually stores the data in a database
(This used to be ctdb commit 167d6993e78f6a1d0f6607ef66925a14993ae6a1)
we cant peek in state->c since this is uninitialized
and even if it were not it would be wrong
create a new structure to pass BOTH client and also the reqid to respond back to
the client with
(This used to be ctdb commit e1a0da3dfbb4a927e8d98723b5e51a201c2a3428)
no locking is yet done and the store_unlock call is still missing
the ./tests/fetch.sh --daemon test fails with parent process dying which needs to be investigated.
(This used to be ctdb commit 7d7141c968950a8856f1be79871932b688bfb07f)
read returns 0 bytes this means the client has exited. Close the connection
then.
(This used to be ctdb commit bd10f4e62146493848258df8a3dc3b9222337a12)
- split client specific routines out of ctdb_daemon.c
- use ctdb_queue code in message send from client to daemon
- use clearer names in client/daemon functions
- use talloc autofree context to avoid global for unlink of socket on
exit
- start on API change for message handler, to allow ctdb messaging to
handle daemon mode with multiple clients
(This used to be ctdb commit 53555db45f3583ae4a32cc3aa9e07fb8ef2a77e3)
we can no longer use this function from the application if we are in daemon mode.
add a horrible "sleep()" to ctdb_test.c to prevent the daemon from dissapearing (parent process died) when the application exits which may happen before the other nodes in the test have finished talking to our daemon
(This used to be ctdb commit 74d35dafe06d71e755f3a58cc58d4b9b56fc821b)
send the correct structure back to a client
assorted other cleanups
(tests/test1.sh now works in daemon mode)
(This used to be ctdb commit f4593754cab750dfdb9384884502e2e1b8fde1f0)
TODO: bugfix (not yet complete, something happens differently than expected
at tcpip when connection is refused in the beginning)
(This used to be ctdb commit 330d76fb91f717d4fb8d1be29c11ddf8c25a4f1c)
