13:20 <gabrielschulhof> otaviobp: Hey! I'll merge that PR, but I found another bug too ...

13:21 <gabrielschulhof> If you call sol_oic_client_del() from the request callback it goes into an infinite recursion ...

13:21 <gabrielschulhof> I think we need to protect the struct sol_oic_client * with a reentrant as well.

13:21 <gabrielschulhof> otaviobp: Javascript brings out the weirdest things, eh?

13:27 <acidx> gabrielschulhof: is that function exposed to JavaScript?

13:29 <gabrielschulhof> Yes.

13:29 <gabrielschulhof> The whole API is exposed.

13:29 <gabrielschulhof> Besides, it should be possible, even from C>

13:30 <gabrielschulhof> Like, if you want to write an app that just issues a query and then quits, why should you need to sol_idle_add(sol_oic_client_del, client)?

13:31 <gabrielschulhof> I mean quits when it gets the response.

13:31 <acidx> I don't know what's the rationale behind exposing even functions like this, since JavaScript has GC and this could potentially be hooked up to that

13:32 <acidx> (it should be possible to do this from C as well, but since there are many other ways to shoot your feet with a shotgun in C...)

13:33 <gabrielschulhof> acidx: The idea with JS exposure is to free as much as possible as soon as possible, since you have access to the pointer anyway. The GC could keep stuff around unnecessarily.

13:33 <gabrielschulhof> As for C, I don't see how having many footguns reduces the need for having this scenario work correctly.

13:34 <gabrielschulhof> In fact, I would say it increases the need for this to work, because forgetting to wrap the cleanup in an idler is one more footgun,

15:44 <gabrielschulhof> otaviobp: /window 2

15:44 <gabrielschulhof> Sorry :)