This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: icecast-1.3.11 port to cygwin


----- Original Message -----
From: "Li-Kai Liu" <news@likai.net>
To: "cygwin" <cygwin@cygwin.com>; <robert.collins@itdomain.com.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]