Re: [ST-devel] libst & large files

[Lev W. <vl...@ne...>]

Wesley W. Terpstra wrote:

> On Mon, Jan 21, 2002 at 12:14:19PM -0800, Lev Walkin wrote:
> 
>>Wesley W. Terpstra wrote:
>>
>>>Has anyone tried to use libst with 64bit large file support on a 32bit
>>>platform?
>>>
>>>I assume it won't work, but wanted to check. I notice that the read/write
>>>apis all use size_t instead of off_t, so I doubt they'll work.
>>>
>>FreeBSD has the 64 bit large file support on 32 bit code. read/write 
>>returns obvious ssize_t, and it is 32 bit in size. So particularly this
>>will work right.
>>
> 
> What the heck. You're right: I just checked my headers, read/write use
> ssize_t even in LFS mode. I suppose that makes sense -- you can't read/write
> more than 2Gb at once even if LFS is enabled. Who'd want to anyways?
> 
> So the API in libst for read/write is fine. I still have concerns though.
> 
> 
>>>Before you say 'why would you need 64bit support for sockets', it's not for
>>>sockets... I want to have the equivalent of 'tail -f' on several files at
>>>the same time I'm watching sockets for incoming requests. These files could
>>>be >> 2Gb.
>>>
>>lseek(fd, 0, SEEK_END);
>>while(1) {
>>	ssize_t rsize;
>>	rsize = read(fd, buf, sizeof(buf));
>>	if(rsize > 0) {
>>		/* Do things */
>>	} else {
>>		usleep(250000);
>>	}
>>}
>>
>>This will work on 32-bit OS'es supporting 64-bit file systems. The off_t 
>>parameter is being used only in lseek().
>>
> 
> However, I want to use libst, so where you have read(...) I'd have to put
> st_read(...). That way libst could context switch and work on other tasks
> while I was waiting for data---the whole point of using it here.
> 
> Suppose I open the file with proper lfs support and do the lseek. This will
> work as you describe above. However, consider this:
> 
> My program is compiled with _FILE_OFFSET_BITS=64 which makes my read
> lfs-aware. Unfortunately, libst does not have this toggle when compiled.


What you probably missing is what the hell is "lfs-aware". 
_FILE_OFFSET_BITS=64 does not change the _read()_ call in any way, so
it should be compatible.


> Hence it's read function (which st_read will call) is not lfs aware and will
> return EOVERFLOW when I call it (section 2.2.1.25 of the X/OPEN LFS spec
> <http://ftp.sas.com/standards/large.file/x_open.20Mar96.html>).
> 
> On the other hand, maybe the spec means that I get EOVERFLOW if I hadn't
> opened it as an lfs-fildes? Perhaps the read is the same and it checks some
> flag on the fildes?
> 
> This is why I was wondering if I could use libst with an lfs system.

Probably, you won't use the st_read instead of read. Why do you need
to do it? st_read() will never return EWOULDBLOCK or EAGAIN on hardware
filesystems, so the thread-switch logic has no meaning on plain files.

-- 
Lev Walkin
vl...@ne...