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
