i did not found any lock of openssl in code
Closed this issue · 11 comments
i found these in the example of libcurl
CRYPTO_set_id_callback((unsigned long ()())thread_id);
CRYPTO_set_locking_callback((void ()())lock_callback);
but why not in your code?
if i run some thread in java code, which use your lib.
is it safe?
i mean all of requests are https
and, it is not real asynchronous?
it seems does not have a task queue, and if one request is running, other request will be blocked?
I remember looking at the locking for OpenSSL but as far as I recall this only applies if you share OpenSSL with other users. In my case, I provide the application with its own OpenSSL library so it will never be shared by anyone else. If you plan to share the openssl lib with other applications or other parts of your app, you might have to consider the locking (check the curl mailing list, I think I even asked about this).
If you implement it feel free to submit a PR.
If you use https in your requests, curl should make them safe by default. curly does not do anything in that aspect.
As for the async part, curl has several modes of operation. You can at least do normal select, you can use the multi api and you can integrate libev or similar. curly uses the multi approach which should handle several requests in parallell. Do note that the posix implementation for the worker thread is currently better than the Win32 version that should really use WaitForSingleObject instead but since I do not use Win32 much I have not fixed that.
thanks for your reply.
btw, i will use your lib to my android project.
it seems it is thread safe, because the all requests in the same worker thread, is right?
so, i can use it in any java threads?
i mean if i use curly_init(&my_cfg); in the JNI_OnLoad, then i can use curly_http_get in any java threads?
btw, in your test code,
curly_http_get("https://google.com", headers, &on_http_get_request_completed);
on_http_get_request_completed is a callback method.
it seems in the work thread, not the main thread, is right?
and i want to know how should i return the request result to my java caller?
please help me
We use curly in both Android and iOS projects with no problems so far. If you find something that can be improved, please share it. In our case curly is initialized by a Java thread that belongs to a pool of threads so I do not thing you should have to worry about which thread is calling it since all the http operations are done using the curly worker anyway.
The callback will for sure be called by the worker thread. If you need to pass the result of the callback to the Java layer you would have to do that over the JNI interface you are using. We have automatized this using Swig. In Swig the way you do callbacks from C to Java (or any managed language) is called "directors". It is a big of a mess to get it right but it works really well. Then once you reach the Java layer, just do a Broadcast or whatever suits your needs (you should ensure the curly worker thread gets released as quickly as possible).
thanks.you did a great job.
you should ensure the curly worker thread gets released as quickly as possible
i do not know what is that mean.
Glad to hear you think its useful. I found curl a little cumbersome to get started with so I wrote this just to make it easier.
My comment about the callback was that you should post the information to another thread so that the callback/worker thread can return and process the next event. Simply ensure the worker thread does not get blocked to do other things in the Java layer. You will probably resolve this using a Broadcast or similar in Android and NSNotification in iOS. As soon as you post that event, the callback/worker thread will be able to return since the Java function is finished.
ok, thanks!
but how to cancel the request?
I have not had a need for that so it is not implemented. Check out how it is done in curl and you should be able to write your own function do accomplish this. (all operations will time out sooner or later if there is for instance a connectivity problem)
ok, thanks...you are nice guy!