apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: shared mem and apr_file_seek
Date Sat, 25 Jan 2014 18:37:51 GMT
Allowing apr_file_trunc() to "fail" with APR_ESPIPE
fixes all issues and passes all tests... committed.

On Jan 25, 2014, at 12:37 PM, Jim Jagielski <jim@jaguNET.com> wrote:

> As can be seen, I'm trying to do some work on shm; in
> case we keep using ftok(...,1) for SysV, I want to make
> posix shm a viable alternative, but I'm running into
> some issues.
> 
> One semi-immediate on is that we do the following:
> 
>    tmpfd = shm_open(shm_name, O_RDWR | O_CREAT | O_EXCL, 0644);
>       ...
>    status = apr_os_file_put(&file, &tmpfd,
>       ...
>    status = apr_file_trunc(file, new_m->realsize);
> 
> And the apr_file_trunc fails for me with an Illegal
> seek. In apr_file_trunc we do:
> 
>    if (ftruncate(fp->filedes, offset) == -1) {
>        return errno;
>    }
>    return apr_file_seek(fp, APR_SET, &offset);
> 
> and apr_file_seek() does a lseek(). And that's where
> the problem is because lseek() returns -1 with ESPIPE.
> 
> That seems like a valid error in this case, which begs
> the following questions:
> 
>  1. Why are we doing the apr_file_trunc() in shm?
>  2. Assuming it's required, why do we expect the lseek
>     on it to succeed?
>  3. Assuming the failure is NOT expected, or is system
>     dependent, how should apr_file_seek handle it?
> 
> 


Mime
View raw message