On Thu, 08.01.2009 at 09:06:45 +0200, Vladimir Terziev wrote:
Hi Matthias,
i configured Ekiga and during the configuration process it didn't find
any Audio device, so i think /dev/dsp* devices must be present, isn't
it ?
Please run
% cat /dev/sndstat
% ls -l /dev/dsp0 /dev/dsp0.0
The
Thank you very much Ulrich!
After running ls -l /dev/dsp0 /dev/dsp0.0 the devices are present and
Ekiga has found them.
The reasonable question is why Ekiga was not able to discover them
without the hack you suggested.
Regards,
Vladimir
On Thu, 2009-01-08 at 10:07 +0200, Ulrich Spoerlein
Hi Matthias,
the version of Ekiga i'm exploring is built from ports and it's
ekiga-2.0.11_4 .
Regards,
Vladimir
On Thu, 2009-01-08 at 10:31 +0200, Matthias Apitz wrote:
El día Thursday, January 08, 2009 a las 09:06:45AM +0200, Vladimir
Terziev escribió:
Hi Matthias,
i configured
El día Thursday, January 08, 2009 a las 09:06:45AM +0200, Vladimir Terziev
escribió:
Hi Matthias,
i configured Ekiga and during the configuration process it didn't find
any Audio device, so i think /dev/dsp* devices must be present, isn't
it ?
Regards,
Vladimir
Which version of
Hi all,
After I had a bit googling I got confused.
My questions are simple and they are as follows :
1-) Are pthreads (or threads in general) of one process scheduled to
different cores on multi-core systems running Linux or BSD?
2-) What if there are multiple processes which have multiple
On Thu, Jan 08, 2009 at 04:23:08AM -0500, Mehmet Ali Aksoy TÜYSÜZ wrote:
Hi all,
After I had a bit googling I got confused.
My questions are simple and they are as follows :
1-) Are pthreads (or threads in general) of one process scheduled to
different cores on multi-core systems
Hi,
Thank you very much for your response Ulf. It is a very clear answer. Thanks
again.
By the way, any information for the Linux case?
Regards,
Mehmet
On Thu, Jan 8, 2009 at 10:08 AM, Ulf Lilleengen ulf.lilleen...@gmail.comwrote:
On Thu, Jan 08, 2009 at 04:23:08AM -0500, Mehmet Ali Aksoy
On tor, jan 08, 2009 at 09:16:26am -0500, Mehmet Ali Aksoy TÜYSÜZ wrote:
Hi,
Thank you very much for your response Ulf. It is a very clear answer. Thanks
again.
By the way, any information for the Linux case?
I think this applies to Linux as well, since it's NPTL(Native Posix Threading
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to go threaded, it
deadlocks because it already appears to have locks held. I am not familiar
enough with the current libthr/libc/rtld-elf interaction that
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to go threaded, it
deadlocks because it already appears to have locks held. I am not familiar
enough
In the last episode (Jan 08), Daniel Eischen said:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat
broken such that when a threaded program forks, and then its child
attempts to go threaded, it deadlocks because it already
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such
that
when a threaded program forks, and then its child attempts to go threaded, it
deadlocks
Ulrich Spoerlein gmail.com!uspoerl...@agora.rdrop.com wrote:
Please run
% cat /dev/sndstat
% ls -l /dev/dsp0 /dev/dsp0.0
The reason you are not seeing them with 'ls /dev/dsp*' is because
devfs is creating the nodes when they are open(2)'ed. Using shell
globbing will search the output of
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to
15 matches
Mail list logo
