<babu_>
no issues, I can handle them in the followup patch
<iscaro>
ok then
<iscaro>
babu_, I'm sorry about that
<babu_>
no problem :)
ceolin[AWAY] is now known as ceolin
ricardotk has joined #soletta
spoussa has joined #soletta
mbelluzzo has joined #soletta
cmarcelo has quit [Quit: Leaving]
bdilly has joined #soletta
spoussa has quit [Ping timeout: 244 seconds]
otaviobp has quit [Remote host closed the connection]
<iscaro>
gabrielschulhof, ping
<gabrielschulhof>
iscaro: What's up?
<iscaro>
do you remenber the reentrant thing?
<gabrielschulhof>
Yes, yes I do. What's up?
<iscaro>
are you sure the usage of SOL_REENTRANT_FREE() is correct?
<iscaro>
let me show an example
<iscaro>
one sec
<iscaro>
nevermind
<iscaro>
lol
<iscaro>
gabrielschulhof, btw. I guess I will create a new macro
<iscaro>
that do not set the delete_me
<iscaro>
but calls the free function if marked delete_me is true
<gabrielschulhof>
Why would you avoid setting delete_me?
<iscaro>
uart needs that
<gabrielschulhof>
Under which circumstances?
<iscaro>
the case is. We call the read_callback from the uart, however I only want to delete the uart handle if the user called uart_close()
<gabrielschulhof>
You can check if delete_me is set.
<iscaro>
I'm doing that
<gabrielschulhof>
So, then that's it.
<iscaro>
but, since we're creating macros for that
<gabrielschulhof>
Nono.
<gabrielschulhof>
There's no encapsulation here.
<gabrielschulhof>
The same thing is happening with discovery.
<gabrielschulhof>
I check if delete_me has been set.
<iscaro>
I saw
<gabrielschulhof>
I actually had a macro called SOL_REENTRANT_IS_STALE() but Gustavo told me that, since all it does is spit back the value of delete_me, it's not worth writing.
<iscaro>
ok then
<iscaro>
good enough
<gabrielschulhof>
Actually, yeah ... definitely! The uart read_callback is exactly the same use case as OIC discovery, because it's an open-ended callback, rather than a one-shot callback.
<gabrielschulhof>
So yeah, <heuristic>for open-ended, you need to check delete_me</heuristic>
<k-s>
iscaro, gabrielschulhof not "is stale", but is stale + free
<k-s>
like SOL_REENTRANT_FREE_IF_NEEDED(handle) if (handle->delete_me && handle->in_use)
<k-s>
oops
<k-s>
like SOL_REENTRANT_FREE_IF_NEEDED(handle) if (handle->delete_me && !handle->in_use)
<gabrielschulhof>
Actually, at least in the OIC case there are other conditions too.
<gabrielschulhof>
Like, if (!cb_return || handle->delete_me)
<k-s>
but those are not specific to reentrant
<k-s>
you can even do: if (!cb_return) handle->reentrant.delete_me = true;
<k-s>
then use the macro
<gabrielschulhof>
No, but what I'm saying is that it's better to leave it unencapsulated, because you have more flexibility for constructing conditionals.
<gabrielschulhof>
k-s: That's exactly what SOL_REENTRANT_FREE does.
<k-s>
the problem is on the other place "free if it was deleted"
<k-s>
not "mark as deleted and free"
<gabrielschulhof>
I understand, and I'm OK with a second macro for such a use case. I just don't see it as being very substantial.
<gabrielschulhof>
It's basically defined as if ((reentrant).delete_me) SOL_REENTRANT_FREE((reentrant))
<k-s>
gabrielschulhof: almost that, but there is no need to call _REE() as you would check delete_me == true, so no need to mark that as true yet again
otaviobp has joined #soletta
siovene has quit [Quit: Connection closed for inactivity]
ceolin is now known as ceolin[AWAY]
spoussa has joined #soletta
ceolin[AWAY] is now known as ceolin
spoussa has quit [Remote host closed the connection]
<k-s>
the quick look doesn't bring me any clear prblem
<k-s>
this code works for an iotivity server, but not for a soletta server
<k-s>
?
<gabrielschulhof>
Yep.
<k-s>
(another nitpick for real code, you could avoid some blobals by using teh `void *data`
<k-s>
)
<k-s>
could you debug where in the server the loop stops?
<gabrielschulhof>
Yeah ...: if (!cbor_value_is_map((CborValue *)map))
<gabrielschulhof>
So, the map is not a map it seems :)
<gabrielschulhof>
"Ceci n'est pas une pipe" :)
<gabrielschulhof>
I'll try sending the request from an iotivity-node client.
<Sachiel>
what are you sending from?
<gabrielschulhof>
Well, I was sending from a soletta client to a soletta server.
<gabrielschulhof>
Writing to the sol_oic_map_writer works fine on the client, so I send the request, but on the server reading from the sol_oic_map_reader does not work.
<k-s>
gabrielschulhof: I don't have the generated flow node type (that uses the sol_oic_client), but it looks like you'd need to create a map :-/
<k-s>
gabrielschulhof: sol_oic_packet_cbor_create() = empty, type == NO_CONTENT
<gabrielschulhof>
Huh? I thought that's the whole point of sol_oic_map_writer - to create it for me - which it does, correctly, because iotivity-node picks it up and displays it.
<k-s>
AFIU it should
<k-s>
makes sense what you said
<k-s>
but I guess since the only code using it is generated, the generator may be emitting the creation call itself
<k-s>
gabrielschulhof: nah, forget what I said, the initialize_cbor_payload() will fix all that is needed
<k-s>
it's better for me to stop guessing, let otaviobp to reply later
<gabrielschulhof>
Well, thanks anyway for trying. I'll call it a day. L8R all!
<k-s>
cya
<k-s>
gabrielschulhof: snd an email or bug report, tag otavio
<k-s>
gabrielschulhof: the sol-oic-gen.py only does the payload on a PUT, not a GET, so no idea if that would interfere