Displaying 5 results from an estimated 5 matches for "thread_sleep".
2003 Jul 31
2
mysql323 + gcc on 4.8-s
...i need a newer compiler.
i'm installing gcc33 from ports, since it's the latest release according
to gnu's site... but running 'make check' (which is still running) has
been spitting out quite a few failures like,
FAIL: SyncGlobal -O execution - bytecode->native test
FAIL: Thread_Sleep output - bytecode->native test
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 execution - bytecode->native test
FAIL: Throw_2 -O execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 -O execution - bytecode->nativ...
2004 Aug 06
2
No source buffering
On Friday 20 February 2004 12:10, Ricardo Galli wrote:
> > wants to send such a patch, we're happy to integrate them. I don't
> > remember the DoS bug - that might be a real problem. It could be that a
>
> It started out with this:
>
> http://www.xiph.org/archives/icecast-dev/0366.html
>
> and I found the problem and sent the patch:
>
>
2004 Aug 06
2
ICECAST enseirb group
...hy not use a
constant
> > macro ?
> >
> > ----------------------------------------
> >
> > In _slave_thread function, there is :
> >
> > ...
> > while (_initialized)
> > {
> > if (max_interval > ++interval)
> > {
> > thread_sleep(1000000);
> > continue;
> > }
> > else
> > ...
> >
> > Can't we do something like :
> > ...
> > while (_initialized)
> > {
> > if (max_interval > interval)
> > {
> > thread_sleep(1000000 * (max_interval -...
2010 Jul 30
33
[PATCHES] Smartjog PatchDump
Hello,
I work at SmarctJog.com, we have here some patches on IceCast for
performance and reliability, these are mostly client/connection/source
cleanups (a slave merge is underway, and some more good stuff (c)),
but we'd like this to be merged in before the list gets any longer.
Please find attached a list of our patches with a short desc:
This one is actually not from us/me, it was found
2004 Aug 06
0
No source buffering
...#39;ve committed it. Sorry I
>missed it the first time (I found it difficult to understand your actual
>email, which is probably why I didn't look at it in more detail originally).
we actually fixed this issue a while back... A continue was added (line 459
of stats.c) which will skip the thread_sleep in the case where there are
pending global events..
also, the global_event_queue pointer has a mutex lock wrapped around access
to it, which your (Ricardo) patch didn't have.
I think it is a fair statement that we regularly and welcome patches from
everyone. But we also reserve the right...