Not sure I like the idea to write code that is not used.
Everything that could be written in a platform agnostic way should be done
this way. The presence of these process/threads specific functions may just
suggest to use them.
Nothing of what we have been doing so far needed this distinction.
Thi
On 19 April 2016 at 14:30, Mike Holmes wrote:
> I have a thought about odph_linux_odpthreads_create() and odph_linux_
> odpthreads_join()
>
> Should these be
>
> odph_odpthreads_create() and odph_odpthreads_join()
>
>
> That way we create the notion of an odpthread that is OS independent and
> th
I have a thought about odph_linux_odpthreads_create() and odph_linux_
odpthreads_join()
Should these be
odph_odpthreads_create() and odph_odpthreads_join()
That way we create the notion of an odpthread that is OS independent and
then the tests possibly extend to another OS without modification.
As I said, our test need to be thread agnostic (because we must test both
model) but those helpers would be for other apps (that are not agnostic). Only
pthread/process validation test cases would be needed (as any other helper
code). Thread creation is so common task for any app that those are
hmmm.
OK. so you want to leave the old functions because they give the
possibility to pass pointers to threads (and get pointer back), whereas
processes would just return an int?
(and by doing the change I did, I had to lower all these to the lowest
common denominator, returning an int in both case
Actually, it’s not the control of thread/process creation but the
representation of those. With pthread create, user expects to give void
*(*start)(void *) function pointer for thread starting point (with void* return
type) and with processes there’s no entry point, but current thread of
execut
On 19 April 2016 at 09:46, Maxim Uvarov wrote:
> On 19.04.2016 10:40, Christophe Milard wrote:
>
>> Thanks for your comment, Petri. You are welcome to point out the coding
>> guideline faults you have seen, so I don't miss them. I will review for the
>> variable declaration position.
>> Regarding
On 19 April 2016 at 09:39, Maxim Uvarov wrote:
> Similar changes can go to one patch. Like the same patches that change
> args for unit tests.
>
Not sure what you mean here. If you mean that the test changes could be
gathered in one single patch I could possibly agree if these changes were
the
On 19.04.2016 10:40, Christophe Milard wrote:
Thanks for your comment, Petri. You are welcome to point out the
coding guideline faults you have seen, so I don't miss them. I will
review for the variable declaration position.
Regarding your other comments, wouldn't it be better to add a fifth
pa
Thanks for your comment, Petri. You are welcome to point out the coding
guideline faults you have seen, so I don't miss them. I will review for the
variable declaration position.
Regarding your other comments, wouldn't it be better to add a fifth
parameter to odph_linux_odpthreads_create() like thi
Similar changes can go to one patch. Like the same patches that change
args for unit tests.
Is that patches sequence buildable?
I think we also need to send this to mailing list. But it's huge number
of small patches which probably might be reasonable
to split on 2 or 3 logical patch sets if
Hi,
Looks reasonable. There are some style / coding guideline faults (like should
introduce all variables in the beginning of a code block). Also pure process
and pthread helpers should remain (suggesting to leave out "helper: removing
dead code"), since not all apps want to obscure whether pro
Hi,
This patch series adds the ability to run tests/ exemples / perf-test
in "process mode" (i.e letting OPD threads being linux processes)
It it hence tackling ODP-171.
This is achieved in 2 main steps:
A]
The 2 pairs of helper functions:
odph_linux_pthread_create(), odph_linux_pthread_join()
a
13 matches
Mail list logo
