lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, Jul 11, 2011 at 20:55, Mike Pall <mikelu-1107@mike.de> wrote:
> Alexander Gladysh wrote:
>> > The underlying OS functions do not expose their lookup paths. You
>> > can easily build this functionality yourself on top of ffi.load().

>> With a chain of pcall-s()... and with reinventing lookup logic (which
>> is exposed in 5.2 only, AFAIR)...

> You mean package.searchpath()? I might add that function, anyway.

Would be cool. (Although, a standalone Lua module would probably be
more beneficial.)

> However this wouldn't completely solve your problem, since you'd
> have to supply the OS-specific path, too. Or you could defer to
> the default lookup if package.searchpath() returns nil.

Yes, of course, the latter is what I intend to do.

> I mean ... for a single local path, this would do just fine:

>  local mypath = "/where/ever/"
>  local function myload(name)
>    local ok, lib = pcall(ffi.load, mypath..name..".so")
>    return ok and lib or ffi.load(name)
>  end

If, say, I have a long list of paths (like tens) and an equal
probability to find the file in any of them, how lots of failed
ffi.load()s will affect the performance? (Sorry for being too sleepy
to write a benchmark myself.)

Alexander.