pwrite() is a standard POSIX system call that is similar to write() but allows the caller to write a supplied buffer of a supplied size to an exact offset in a file.

Here is the doc on pwrite() and write():

http://www.opengroup.org/onlinepubs/000095399/functions/write.html

Cheers!

Jay

replication is going to Rock!

First of all, there aren’t any stupid questions. All of this code is extremely new!

So, on line 41:

cur_offset-= static_cast((total_envelope_length));

You are correct that we are recalculating the original offset there. The reason we do this is to “cut out” a chunk of the log file that we will use for writing the current transaction message.

Because TransactionLog::apply() is code that is run in a threaded server, the variables of the TransactionLog such as the log_offset variable must be protected against changes from another thread’s execution of the TransactionLog::apply() method.

The log_offset variable is of type drizzled::atomic. This means that it’s contents follow the atomic<> API templates implemented in /drizzled/atomic/. This template provides methods which ensure synchronized writes of a variable’s contents in a threaded environment. The atomci<>.fetch_and_add() method atomically increments a variable’s contents and returns the contents of the variable.

On line 35:

cur_offset= log_offset.fetch_and_add(static_cast(total_envelope_length));

what we are doing is carving out a chunk of space in the log file long enough to write our complete log entry. We “carve” this chunk out by simply atomically incrementing the log_offset. Once incremented, the new log_offset value is returned from fetch_and_add(), and we must therefore subtract the length of the transaction message we will write in order to return to the exact offset into the transaction log that we will write into.

Hope the above makes sense!

Cheers!

Jay

sorry if i am coming with stupid points.
in TransactionLog::apply line no 41
it looks like offset is moving forward and then calculating and moving backward. is it something which can be avoided?

as you said the dynamic allocation is an issue.
anyway writing need to be serial. so what is the possibility of singleton for write operation?

Thank you,
Jobin.