Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"attempt to yield across C-call boundary" occur while connect() #3

Closed
bigplum opened this issue Apr 7, 2012 · 8 comments
Closed

"attempt to yield across C-call boundary" occur while connect() #3

bigplum opened this issue Apr 7, 2012 · 8 comments

Comments

@bigplum
Copy link

@bigplum bigplum commented Apr 7, 2012

I package redis functions into a module testdb.lua, and include it in another module testm.lua.

testm.lua is required in test.lua, which is running by ngx_lua:

content_by_lua_file luas/test.lua;

Finally, the error occur:

2012/04/07 22:10:32 [error] 24794#0: *185113 1, client: 127.0.0.1, server: localhost, request: "GET /test HTTP/1.1"
2012/04/07 22:10:32 [error] 24794#0: *185113 lua handler aborted: runtime error: attempt to yield across C-call boundary, client: 127.0.0.1, server: localhost, request: "GET /test HTTP/1.1"

The first ngx.log() is excuted, but second not. So is there anything wrong in redis:connect()?

All the files could be found in: https://gist.github.com/2329313

thanks.

@bigplum
Copy link
Author

@bigplum bigplum commented Apr 7, 2012

If we put get_rtdb() into a function, it works well.

https://gist.github.com/raw/2329313/691fac7cbfac56ea331c1866e0c32400d271942d/testm1.lua

curl localhost/test
ok testm
ok test

@agentzh
Copy link
Member

@agentzh agentzh commented Apr 17, 2012

It seems that the require function is implemented as a C function, which cannot be yielded in the middle of the require call. The LuaJIT implementation does not support yielding across the C function call boundary, just like the standard Lua 5.1 interpreter. Your work-around indeed eliminated this and hence worked.

@bigplum
Copy link
Author

@bigplum bigplum commented Apr 19, 2012

It looks like you said.

@yangm97
Copy link

@yangm97 yangm97 commented Oct 29, 2017

Sorry if I’m stealing this issue, but I still don’t get how to work around this. Here’s my situation:

database.lua

local config = require 'config'

local red

if ngx then
	local redis = require 'resty.http'
	red = redis:new()
	red:connect(config.redis.host, config.redis.port)
else
	local redis = require 'redis'
	red = redis.connect(config.redis.host, config.redis.port)
end

red:select(config.redis.db)

return red

main.lua and many other “plugins”:

local db = require ‘database’
…
db:hset('bot:usernames', '@'..msg.from.username:lower(), msg.from.id)
...

So I have this wrapper mainly because my application can run either with or without openresty and because I wanted to avoid copy-pasting (the somewhat big) database connection code.

The error message is the same (lua entry thread aborted: runtime error: attempt to yield across C-call boundary).

@agentzh
Copy link
Member

@agentzh agentzh commented Oct 29, 2017

@yangm97 Your usage is wrong. Please read the documentation more carefully:

https://github.com/openresty/lua-resty-redis/#limitations

@agentzh
Copy link
Member

@agentzh agentzh commented Oct 29, 2017

@yangm97 Also, read the discussion above.

@yangm97
Copy link

@yangm97 yangm97 commented Oct 29, 2017

I read both. Also I kind see where it’s failing and why (“The resty.redis object instance cannot be stored in a Lua variable at the Lua module level”) but I really don’t see a solution other than copy-pasting 13 lines of code across ~30 files to work around this.

@seven1240
Copy link

@seven1240 seven1240 commented Apr 29, 2019

seems set on ngx.ctx works for me

local resty_redis = require "resty.redis"
local redis = resty_redis:new()

redis:set_timeout(1000) -- 1 sec
ngx.ctx.redis = redis

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants