No, using SIGEV_THREAD will create one worker thread per timer created.
Posix doesn't specify this level of implementation detail. In Bionic, we
want to keep things simple
and using one thread per timer achieves that.
At the opposite spectrum, you'll find GLibc which uses some very
sophisticated
Hi One more Q for you
> Yes, it is, but frankly you should be using a single SIGEV_THREAD timer with
> your own sorted timer list
Do that means SIGEV_THREAD functionality will put the timers in one
event list and sort them all together ? and timeouts will happen
similar to POSIX signals ? or use
Yes, it is, but frankly you should be using a single SIGEV_THREAD timer with
your own sorted timer list
On Thu, Feb 12, 2009 at 2:14 PM, Girish wrote:
>
> Hi,
>
> Is SIGEV_THREAD is part of open source and cupcake code now ? With
> SIGEV_THREAD also i guess we should be able to create 32 timers
Hi,
Is SIGEV_THREAD is part of open source and cupcake code now ? With
SIGEV_THREAD also i guess we should be able to create 32 timers per-
process right ? Can any one point me out using threads over signals
for timer operation.
Regards
Girish
--~--~-~--~~~---~--~---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Girish wrote:
[...]
> The above explanation will hold only good if and only if the timers
> are in ascending order or descending order.Not ina random fashion
> which i missed to mention
Well, sort them then! Remember, time *only* increments. It does
Hi Davi,
Could you suggest any links on the web to look into ! We need around
25 timers which can run in parallel. Similar functionality what POSIX
timers support.
Regards
Girish
On Feb 2, 5:10 pm, David Turner wrote:
> I suggest you to look at POSIX's timer_create() and related functions.
>
>
On Mon, Feb 2, 2009 at 12:51 PM, Vandana Vuthoo wrote:
> Hi All,
> Want to know if anybody has added hardware acceleration on TI OMAP
> platform.
Please start your own thread on this list rather than adding off-topic
discussion to an existing one.
This will make the thread much more easily disco
I suggest you to look at POSIX's timer_create() and related functions.
If you want your handlers to run in parrallel, just use one distinct
SIGEV_THREAD per timer.
No need to use any signals here.
On Mon, Feb 2, 2009 at 3:46 AM, Girish wrote:
>
> David,
>
> Thanks,
>
> How should the problem be
Hi All,
Want to know if anybody has added hardware acceleration on TI OMAP platform.
Rgds.
Vandana
--~--~-~--~~~---~--~~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~--~~~~---
Hi David,
I have developed it using threads.
For every timer there is a corresponding thread. and time for what
timer is set i made thread to sleep.
thread is kept sleeping for timed out "time".
After that i call callback function.
is this right method
Thanks
kuldeep
On Feb 2, 10:03 am, G
Just put all of your timers in one event list and sort them all together,
then we you dispatch each event call the appropriate code for that timer.
On Sun, Feb 1, 2009 at 9:03 PM, Girish wrote:
>
> Hi David,
>
> The above explanation will hold only good if and only if the timers
> are in ascendi
Hi David,
The above explanation will hold only good if and only if the timers
are in ascending order or descending order.Not ina random fashion
which i missed to mention
Timer1 start --- > 10sec --- > 1sec,2sec,..10 sec
Timer2 start ---> 15sec > 1sec,
2sec .
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Girish wrote:
[...]
> Timer1 start --- > 10sec --- > 1sec,2sec,..10 sec
> Timer2 start ---> 15sec > 1sec,
> 2sec ...15sec
> ... Like this Timer1 and Timer2 will execute in parallel.
>
> Can you
David,
Wht i mean is that timeout values will be in parallel
Timer1 start --- > 10sec --- > 1sec,2sec,..10 sec
Timer2 start ---> 15sec > 1sec,
2sec ...15sec
... Like this Timer1 and Timer2 will execute in parallel.
Can you explain more ab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Girish wrote:
> As middleware application demands the timeout values cant be kept in
> sorted list. Say i have timeout values 1,3000,15,17000 .so
> it cant workout ... Is there any alternative way to acheive this ?
I'm afraid I don't foll
David,
Thanks,
How should the problem be resoloved in our case ? SIGRTMIN and
SIGRTMAX was available in the previous port of middleware application
and it was a difference of 32 between.So per process we were able to
create at the max of 32 timers for our middleware C application..
(SIGRTMAX-SIG
the cupcake C library already supports real-time timers through
timer_create().
real-time signals are a different thing and they are not currently
supported.
For the record, with other C libraries, not all of SIGRTMIN .. SIGRTMAX is
available to application-defined purposes.
The implementation usu
Hi David,
As middleware application demands the timeout values cant be kept in
sorted list. Say i have timeout values 1,3000,15,17000 .so
it cant workout ... Is there any alternative way to acheive this ?
Regards
Girish
On Feb 2, 7:23 am, David Given wrote:
> -BEGIN PGP SIGNED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Girish wrote:
[...]
> Will there be any support for POSIX RT timers in near future. As the
> application needs more than 20 timers.
It's trivial to implement as many timers as you like in user space;
simply keep them in a sorted list, and use your s
Hi David,
Will there be any support for POSIX RT timers in near future. As the
application needs more than 20 timers. In POSIX it was achievable
because of the fact that it was supporting SIGRTMIN to SIGRTMAX, are a
set of signals that can be used for application-defined purposes.
> Or using on
Maybe by using a single signal with a sorted timer queue ?
Or using one thread per timer, each one simply doing a timed wait ?
Any code that requires 25 signals is not going to work, on any platform
On Fri, Jan 30, 2009 at 1:16 AM, kd.itbhu wrote:
>
> Hi;
> I need around 25 times which can run
21 matches
Mail list logo
