curl / Mailing Lists / curl-library / Single Mail



From: Pete Lomax via curl-library <>
Date: Fri, 26 Jan 2018 16:12:31 +0000 (UTC)

I have written a wrapper for libcurl for my language, Phix (, and found that the
CURLOPT_DEBUGFUNCTION option does not play nicely with my threads. Rightly or wrongly,
I have implemented threads using heap-allocated call stack blocks, and thread control
blocks to achieve mostly lock-free heap management, however should libcurl invoke
CreateThread/sys_fork without my knowledge and then invoke a callback from the new
thread, it crashes because there is no call stack (and no sensible point at which to
tear my stuff down). For now, I have managed to implement a low-level assembly version,
but that is less than ideal.

Hence I would ask you to consider a CURLOPT_THREADFUNCTION or similar which gives my
runtime a chance to manage thread creation and termination (I am assuming the latter could be
signified by a NULL in one of the arguments to the callback).

During initial investigations I stumbled upon the slightly related nopoll_thread_handlers
which actually [NB] solves a completely different problem, ie locking.
To be honest, I am by no means certain that would have any use, but I would note that it
seems tailor-made for a language like mine. What I am looking for is something similar
(or quite different) but for threads not locks. I might also (cheekily) suggest that any testing you
might want to do should probably begin with maintaining a searchable table of thread-ids.

Received on 2018-01-26