|
From: Travis B. <tr...@be...> - 2005-04-18 05:56:58
|
I agree with just about all of your plan. The "right way" to do the configure scripts is to test for functionality rather than system type, but that's more work. Short term, we can just check for FreeBSD. Long term, we can perhaps switch to gthreads (I know little to nothing about the comparative advantages of different threading libraries, so I leave this to you guys to decide). It's just a matter of taste, but I'd rather see a simple preprocessor macro in the source than redefining sem_open to sem_init--that could create confusion for anyone reading the source. How about # ifdef _USE_SEM_OPEN // Use this on systems where sem_open is available. sem_open( .... ); #endif // Otherwise # ifndef _USE_SEM_OPEN // sem_open is broken -- use sem_init sem_init( ... ); #endif Not the prettiest solution, but very clear and understandable. I might be mucking with my kernel anyway for other reasons (fixing stubborn sound & DVI / video problems). If I do, I'll try the experimental threading code... -Travis On Apr 17, 2005, at 8:31 PM, Matthew W. Jones wrote: > Daniel,Travis: > > Well, what I would do is check to see if it is FreeBSD and then have > it link > against libc_r instead of libpthread, this is a passive change and can > take > place without having to run an extra script at configure time. > > There is some good documentation here: > http://www.unobvious.com/bsd/freebsd-threads.html > > about the different threading implementations. > > From some of the documentation that I have read I see that P1003.1b > Semaphores > are still very experimental in FreeBSD and I'm not sure when this will > change: > > http://lists.freebsd.org/pipermail/freebsd-questions/2004-February/ > 035156.html > > You can test the new semaphore code in your kernel if you want, add > this to > your kernel config: > > options P1003_1B_SEMAPHORES > > at the moment, for me, libmap works for me in the interim. > > A couple of possible solutions would be: to #undef FreeBSD's sem_open > and then > redefine it as sem_init which wouldn't be so bad even though they take > different parameters, or force it to link against libc_r... which > would seem to > work better in the mean time for a couple of reasons: 1) Our > threading > implementation is a moving target... Daniel has mentioned beginning to > work on > the threading and 2) It would not involve any extra code or > preprocessor macros > in the source file itself... which is a plus. > > I would propose, especially since we are using glibc that we use > libgthread. > This would make it more consistent and take away all of these problems > (I > believe). I am using gthreads in several places right now and have > been quite > pleased with them. > > Comments? > M > > On 16-Apr-2005 Travis Beals wrote: >> Hi Matt, >> >> That sounds like a good fix for BSD, but wouldn't it be better to have >> configure just compile & run a code snippet that calls sem_open(), see >> if it crashes, then adjust accordingly? That way we're making the >> decision in a platform independent way. If BSD ever fixes libpthread, >> then we'll automatically go back to using it (I assume there's some >> advantage in to using it over libc_r, in theory--Daniel must have had >> a >> reason for making sem_open preferred over sem_init). >> >> -Travis >> >> >> >> On Apr 15, 2005, at 8:51 PM, Matthew W. Jones wrote: >> >>> I will go ahead and include a modification to the Make flags in my >>> upcoming >>> patch to make FreeBSD link against libc_r instead of libpthread. >>> I'll >>> also >>> test this on NetBSD and OpenBSD to see if either of them suffer from >>> a >>> similar >>> problem. >>> >>> Since I have to be mucking around with the configure scripts anyway >>> ;) >>> >>> M >>> >>> >>> On 16-Apr-2005 Matthew W. Jones wrote: >>>> Hey Travis, >>>> >>>> I figured out what I did that you probably have not done to get >>>> around the >>>> sem_open problem, sorry it's been a while since I had to overcome >>>> some of >>>> these >>>> issues. >>>> >>>> I had to use a libmap.conf (/etc/libmap.conf) to change what >>>> threading >>>> library >>>> xgridagent uses. I had problems with the base libpthread and >>>> libkse so I >>>> had >>>> to switch it to use the older libc_r threading library, here's the >>>> relevant >>>> section of my libmap: >>>> >>>> <code> >>>> [xgridagent] >>>> libpthread.so.1 libc_r.so.5 >>>> libpthread.so libc_r.so >>>> </code> >>>> >>>> I'm in the process of reworking my patch to be optional at the >>>> moment. >>>> Hopefully I can get it this weekend :) >>>> >>>> >>>> -- >>>> ---------------------------------- >>>> E-Mail: Matthew W. Jones <ma...@os...> >>>> Date: 15-Apr-2005 >>>> Time: 22:34:50 >>>> >>>> http://matburt.homeunix.com >>>> http://oss-institute.org >>>> >>>> This message was sent by XFMail >>>> ---------------------------------- >>>> >>>> >>>> ------------------------------------------------------- >>>> SF email is sponsored by - The IT Product Guide >>>> Read honest & candid reviews on hundreds of IT Products from real >>>> users. >>>> Discover which products truly live up to the hype. Start reading >>>> now. >>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>> _______________________________________________ >>>> Xgridagent-development mailing list >>>> Xgr...@li... >>>> https://lists.sourceforge.net/lists/listinfo/xgridagent-development >>> >>> -- >>> ---------------------------------- >>> E-Mail: Matthew W. Jones <ma...@os...> >>> Date: 15-Apr-2005 >>> Time: 22:49:17 >>> >>> http://matburt.homeunix.com >>> >>> This message was sent by XFMail >>> ---------------------------------- >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Xgridagent-development mailing list >>> Xgr...@li... >>> https://lists.sourceforge.net/lists/listinfo/xgridagent-development >>> > > -- > ---------------------------------- > E-Mail: Matthew W. Jones <ma...@os...> > Date: 17-Apr-2005 > Time: 21:53:21 > > http://matburt.homeunix.com > > This message was sent by XFMail > ---------------------------------- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xgridagent-development mailing list > Xgr...@li... > https://lists.sourceforge.net/lists/listinfo/xgridagent-development > |