>
> I found on posix writev that stbuf is local , but a ptr to it is returned
> to caller.
The callback path of transaction is not actually C stack unwinds. So passing
pointers from the stack to STACK_WIND and STACK_UNWIND is fine, as long as
the fops ahead do not store the pointer for 'later use'.
int32_t
> posix_writev (call_frame_t *frame,
> xlator_t *this,
> fd_t *fd,
> struct iovec *vector,
> int32_t count,
> off_t offset)
> {
> int32_t op_ret;
> int32_t op_errno;
> int32_t _fd;
> struct posix_private *priv = this->private;
> data_t *pfd_data = dict_get (fd->ctx, this->name);
> struct posix_fd *pfd;
> struct stat stbuf = {0,};
>
> ...
> ...
> STACK_UNWIND (frame, op_ret, op_errno, &stbuf);
>
> }
>
> Upper modules (for example my pet QUOTA) declare args as:
>
> static int32_t
> quota_writev_cbk (call_frame_t *frame,
> void *cookie,
> xlator_t *this,
> int32_t op_ret,
> int32_t op_errno,
> struct stat *buf)
>
> Shouldnt be stat declared as 'struct stat const *buf'?
why?
also as stat is local to posix_writev can two or more threads hold a ponter
> to it while serving diferent requests and thus cause a race condition??
As I mentioned previously, no fops are supposed to store the pointer. they
can only immediately STACK_WIND/STACK_UNWIND with the pointer (essentially
meaning the pointer usage scope is within the same thread only).
We plan to capture all these nitty-gritty details in the hackers guide.
thanks for your interesting questions.
avati
--
If I traveled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.
