Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <00c101c13f09$6dac0490$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Li-Kai Liu" <news AT likai DOT net>, "cygwin" <cygwin AT cygwin DOT com>
References: <3BA5218D DOT 6050005 AT likai DOT net> <009001c13f01$8fec9bd0$0200a8c0 AT lifelesswks> <3BA53359 DOT 9040000 AT likai DOT net>
Subject: Re: icecast-1.3.11 port to cygwin
Date: Mon, 17 Sep 2001 09:43:45 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 16 Sep 2001 23:30:23.0135 (UTC) FILETIME=[8E82EAF0:01C13F07]

----- Original Message -----
From: "Li-Kai Liu" <news AT likai DOT net>
To: "cygwin" <cygwin AT cygwin DOT com>; <robert DOT collins AT itdomain DOT com DOT au>
Sent: Monday, September 17, 2001 9:18 AM
Subject: Re: icecast-1.3.11 port to cygwin


> i'm just a poor fellow trying to port icecast to cygwin, and i'm not
> associated with icecast development team. :(
>
> as i'm still studying the case myself, i just felt that I could make
> announcement based on what I already know. apparantly icecast uses
their
> own thread management functions that traces active threads within the
> process. in cygwin prior to 1.3.3, icecast would complain during
> thread_init that "mt: thread never made to life ... weird" while the
> same time it says something like "unknown thread is running." I've
> reported to the icecast team and all they told me was not to use
cygwin
> because pthread is broken. all I know is icecast tries to check the
> thread pointer using pthread_self() function and for some reason it
> doesn't return a reliable value.

I don't believe this has changed from pre 1.1.8. (in other words, in a
long time :}). pthread_equal was broken at one point though (between
1.1.8 and 1.3.2, and then fixed again for 1.3.3).

If the icecast team consider cygwin pthreads broken, they might consider
submitting bug reports. I'm quite active in tracking down the problem
once I've got a good pointer. (This is a general issue, from time to
time I hear things like "xyz is broken" and when I enquire, the "xyz"
developers _have not been told_!.

> i have a question though: does pthread_detach() in cygwin (before
1.3.3)
> change anything that is returned from pthread_self()? because i
noticed

No. pthread_detach changes the behaviour of exiting threads, not their
identifiers.

> how, after creating the thread, icecast calls this function. i
strongly
> feel this has something to do with the phenomenon. anyhow, this
problem
> is not present in cygwin 1.3.3 anymore, so i'd like to focus on other
> two problems.
>
> - inability to catch signal ... i have no idea where to start finding
> the source of problem for this. can you give me a hint?

Well to start with grab the Cygwin source
(http://www.cygwin.com/contrib.html) and build yourself a debug .dll.
(You'll need that :} ).

Chris Faylor just wrote a "how-signals-works.txt" file, which you will
find in the source tarballs. Read that. Then start test cases I guess.
I.e. can you catch the signal during sleep()? Is it only catching the
signal on I/O that matters? and so forth. Once you've got a reproducible
minimal test case, then start thinking about how to correct it. I
suggest that at that point it's appropriate to bring the issue up here,
so we can all discuss it. It may be one of the "we really don't know how
to do x" issues, or perhaps we will have some pointers for things for
you to try.

> - coredump when waiting for threads to exit ... i will study this some
more.

This shouldn't happen. Attach to the program with gdb, and your debug
.dll, and see where they are crashing.

> and as i said at the beginning, i'm not an active developer for
icecast,

However, from my point of view, you
a) understand icecast more than I do
b) want it to work on cygwin
c) are willing to put time and effort into doing so.

So I'd call you the icecast cygwin developer team ;}.

> so i'm just trying to bring icecast over to cygwin. the icecast
> developers don't seem to be keen about this port. (also, this is *not*
> my program).

It is for the purposes of this exercise.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/