I have written a wrapper for libcurl for my language, Phix (http://phix.x10.mx), 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
(http://www.aspl.es/nopoll/html/group__nopoll__module_ga7f2a26a896c1416b23933097a993a435.html)
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.

Regards,
Pete
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-01-26