Yes, it is safe to delete it in after callback. Generally the rule of thumb here is that the struct could be deleted after it is not used or was closed.
On Thu, Dec 18, 2014 at 10:50 AM, William Ehlhardt < [email protected]> wrote: > > On Wed, Dec 17, 2014 at 9:28 PM, Fedor Indutny <[email protected]> wrote: >> >> Every request, be it write/shutdown/queue_work is allocated by user and >> must be kept alive. >> > > Right. So when is it safe to delete the uv_work_t? It would be most > convenient to be able to free() it during the "after" callback in my > queue.c. Is it safe to do that? > > If not, how should I manage the pending uv_work_t objects? Should I keep a > list of them somewhere and mark them as "done" in the "after" callback, > then have some other means of cleaning them up later? > > > > >> >> Cheers, >> Fedor. >> >> On Thu, Dec 18, 2014 at 9:38 AM, William Ehlhardt < >> [email protected]> wrote: >>> >>> I thought about this some more. Obviously in (2), user code has to be >>> responsible for deletion, since uv_queue_work takes a pointer that could be >>> to a stack-allocated uv_work_t. So the question remains: when is it safe to >>> delete the uv_work_t? >>> >>> On Wednesday, December 17, 2014 8:31:20 PM UTC-6, William Ehlhardt wrote: >>> >>>> Hi folks, >>>> >>>> In the attached file, I delete a uv_work_t after running uv_queue_work, >>>> which causes a use-after-free crash. This is somewhat surprising behavior. >>>> >>>> 1. The documentation does not make it clear that the uv_work_t passed >>>> to uv_queue_work needs to remain alive until (presumably?) the callbacks >>>> have all completed, which leads to: >>>> >>>> 2. Since uv_queue_work spins off another thread to do the work, and >>>> since this may happen in a context where you're spinning many uv_work_t >>>> tasks off to run simultaneously, it's not clear where the uv_work_t should >>>> be deleted. Declaring it on the stack of the caller of uv_run isn't a very >>>> good solution because you can't stack-declare arbitrary numbers of >>>> uv_work_t, which you need to do if you're potentially queuing lots of >>>> background work at once. Allocating it on the heap, meanwhile, brings up >>>> the question of (A) is user code responsible for deleting the uv_work_t, or >>>> is libuv? and (B) if user code is responsible, when is it safe to delete >>>> the work_t? During the "done" callback? >>>> >>>> -William >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "libuv" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/libuv. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "libuv" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/libuv/MBl46Ofe2Is/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/libuv. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
