xgridagent-development Mailing List for XGridAgent

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

This is from xgrid-users, just thought you guys might be interested:

http://developer.apple.com/documentation/Performance/Conceptual/XgridDev
eloper/index.html

Cheers,

Bernard

Hey guys:
=20
Does anybody know what is the oldest version of libxml2 that will work =
with xgridagent 1.0.3?  In other words, which version has support for =
xmlStrncatNew?  The installation guide seems to point at 2.6.9, but I'm =
just double-checking here.
=20
Thanks,
=20
Bernard

Hey Travis:

I'm not sure how different Xgrid on Tiger Server is from Tiger
(non-Server), but it would be great if xgridagent will work on both.
Someone wrote a GUI frontend to the command line interface to manage
Xgrid server on Tiger (non-Server).

Cheers,

Bernard=20

> -----Original Message-----
> From: xgr...@li...=20
> [mailto:xgr...@li...]=20
> On Behalf Of Travis Beals
> Sent: Friday, May 27, 2005 15:29
> To: Matthew W.Jones
> Cc: xgr...@li...
> Subject: Re: [Xgridagent-development] Tiger, use of howl
>=20
> OK, great. Do you have OS X Tiger Server available?  There are hacks =20
> to circumvent the limitations, but officially, Xgrid now requires an =20
> OS X Server box as a controller. I have OS X Server, so I can=20
> do some =20
> tests, or perhaps just give you an account on the machine.
>=20
> -Travis
>=20
> On May 27, 2005, at 3:09 PM, Matthew W. Jones wrote:
>=20
> > I'm actually still using an old version of XGrid on Tiger (Doesn't =20
> > work
> > as well either, it's still useable from the command line). =20
> I'll give
> > the new XGrid a try this weekend.
> >
> > I've noticed the issues with libHowl, I'm working on a replacement
> > implementation... I'll let you guys know when it's done.  Either way
> > 1.0.3 will stay on LibHowl.
> >
> > Mat
> >
> > On 25-May-2005 Travis Beals wrote:
> >
> >> I finally got my Xserve upgraded to Tiger, although it was hell
> >> (somehow Tiger broke KDE on some of my BSD machines that NFS-mount
> >> home directories from the xserve). Now, it seems that xgridagent
> >> won't talk to the new controller. Matthew, are you running Tiger
> >> Server successfully as a controller for a grid containing=20
> Xgridagent
> >> agents? Daniel implied that this wouldn't work, and I'm inclined to
> >> agree with him, although I may just have missed something. Does
> >> anyone know how much work is involved in making xgridagent=20
> compatible
> >> again?
> >>
> >> As a minor consideration for future planning, it looks=20
> like there are
> >> some license issues with Howl that indirectly affect us.=20
> Basically, a
> >> number of linux distributions (Debian, for example) don't like the
> >> patent clause in the APSL, and so won't include Howl. People can
> >> always download and compile Howl themselves, but that's a bit
> >> inconvenient.  See this email:
> >>
> >> http://lists.porchdogsoft.com/pipermail/howl-users/2005-April/
> >> 000614.html
> >>
> >> There are apparently other mDNS / ZeroConf implementations (e.g.
> >> Avahi) either available or under development that do not have these
> >> issues. Long-term, we should perhaps consider switching to one of
> >> them. It doesn't seem that Avahi is quite ready for primetime yet,
> >> though, so we should stick with Howl for now.
> >>
> >> -Travis
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by Yahoo.
> >> Introducing Yahoo! Search Developer Network - Create apps using =20
> >> Yahoo!
> >> Search APIs Find out how you can build Yahoo! directly=20
> into your own
> >> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-=20
> >> ostg-q22005
> >> _______________________________________________
> >> Xgridagent-development mailing list
> >> Xgr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/xgridagent-development
> >>
> >
> > --=20
> > ----------------------------------
> > E-Mail: Matthew W. Jones <ma...@os...>
> > Date: 27-May-2005
> > Time: 17:06:31
> >
> > http://matburt.homeunix.com
> >
> > This message was sent by XFMail
> > ----------------------------------
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps=20
> using Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your own
> > Applications - visit=20
> http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-=20
> > q22005
> > _______________________________________________
> > Xgridagent-development mailing list
> > Xgr...@li...
> > https://lists.sourceforge.net/lists/listinfo/xgridagent-development
> >
>=20
>=20

I have an X-Serve running Tiger server, though it's good to know that
we'll have a couple of people to be able to test it :)

Mat

On 27-May-2005 Travis Beals wrote:
> OK, great. Do you have OS X Tiger Server available?  There are hacks  
> to circumvent the limitations, but officially, Xgrid now requires an  
> OS X Server box as a controller. I have OS X Server, so I can do some  
> tests, or perhaps just give you an account on the machine.
> 
> -Travis
> 
> On May 27, 2005, at 3:09 PM, Matthew W. Jones wrote:
> 
>> I'm actually still using an old version of XGrid on Tiger (Doesn't  
>> work
>> as well either, it's still useable from the command line).  I'll give
>> the new XGrid a try this weekend.
>>
>> I've noticed the issues with libHowl, I'm working on a replacement
>> implementation... I'll let you guys know when it's done.  Either way
>> 1.0.3 will stay on LibHowl.
>>
>> Mat
>>
>> On 25-May-2005 Travis Beals wrote:
>>
>>> I finally got my Xserve upgraded to Tiger, although it was hell
>>> (somehow Tiger broke KDE on some of my BSD machines that NFS-mount
>>> home directories from the xserve). Now, it seems that xgridagent
>>> won't talk to the new controller. Matthew, are you running Tiger
>>> Server successfully as a controller for a grid containing Xgridagent
>>> agents? Daniel implied that this wouldn't work, and I'm inclined to
>>> agree with him, although I may just have missed something. Does
>>> anyone know how much work is involved in making xgridagent compatible
>>> again?
>>>
>>> As a minor consideration for future planning, it looks like there are
>>> some license issues with Howl that indirectly affect us. Basically, a
>>> number of linux distributions (Debian, for example) don't like the
>>> patent clause in the APSL, and so won't include Howl. People can
>>> always download and compile Howl themselves, but that's a bit
>>> inconvenient.  See this email:
>>>
>>> http://lists.porchdogsoft.com/pipermail/howl-users/2005-April/
>>> 000614.html
>>>
>>> There are apparently other mDNS / ZeroConf implementations (e.g.
>>> Avahi) either available or under development that do not have these
>>> issues. Long-term, we should perhaps consider switching to one of
>>> them. It doesn't seem that Avahi is quite ready for primetime yet,
>>> though, so we should stick with Howl for now.
>>>
>>> -Travis
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by Yahoo.
>>> Introducing Yahoo! Search Developer Network - Create apps using  
>>> Yahoo!
>>> Search APIs Find out how you can build Yahoo! directly into your own
>>> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn- 
>>> ostg-q22005
>>> _______________________________________________
>>> Xgridagent-development mailing list
>>> Xgr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xgridagent-development
>>>
>>
>> -- 
>> ----------------------------------
>> E-Mail: Matthew W. Jones <ma...@os...>
>> Date: 27-May-2005
>> Time: 17:06:31
>>
>> http://matburt.homeunix.com
>>
>> This message was sent by XFMail
>> ----------------------------------
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Yahoo.
>> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
>> Search APIs Find out how you can build Yahoo! directly into your own
>> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg- 
>> q22005
>> _______________________________________________
>> Xgridagent-development mailing list
>> Xgr...@li...
>> https://lists.sourceforge.net/lists/listinfo/xgridagent-development
>>
> 

-- 
----------------------------------
E-Mail: Matthew W. Jones <ma...@os...>
Date: 27-May-2005
Time: 17:40:57

http://matburt.homeunix.com

This message was sent by XFMail
----------------------------------

OK, great. Do you have OS X Tiger Server available?  There are hacks  
to circumvent the limitations, but officially, Xgrid now requires an  
OS X Server box as a controller. I have OS X Server, so I can do some  
tests, or perhaps just give you an account on the machine.

-Travis

On May 27, 2005, at 3:09 PM, Matthew W. Jones wrote:

> I'm actually still using an old version of XGrid on Tiger (Doesn't  
> work
> as well either, it's still useable from the command line).  I'll give
> the new XGrid a try this weekend.
>
> I've noticed the issues with libHowl, I'm working on a replacement
> implementation... I'll let you guys know when it's done.  Either way
> 1.0.3 will stay on LibHowl.
>
> Mat
>
> On 25-May-2005 Travis Beals wrote:
>
>> I finally got my Xserve upgraded to Tiger, although it was hell
>> (somehow Tiger broke KDE on some of my BSD machines that NFS-mount
>> home directories from the xserve). Now, it seems that xgridagent
>> won't talk to the new controller. Matthew, are you running Tiger
>> Server successfully as a controller for a grid containing Xgridagent
>> agents? Daniel implied that this wouldn't work, and I'm inclined to
>> agree with him, although I may just have missed something. Does
>> anyone know how much work is involved in making xgridagent compatible
>> again?
>>
>> As a minor consideration for future planning, it looks like there are
>> some license issues with Howl that indirectly affect us. Basically, a
>> number of linux distributions (Debian, for example) don't like the
>> patent clause in the APSL, and so won't include Howl. People can
>> always download and compile Howl themselves, but that's a bit
>> inconvenient.  See this email:
>>
>> http://lists.porchdogsoft.com/pipermail/howl-users/2005-April/
>> 000614.html
>>
>> There are apparently other mDNS / ZeroConf implementations (e.g.
>> Avahi) either available or under development that do not have these
>> issues. Long-term, we should perhaps consider switching to one of
>> them. It doesn't seem that Avahi is quite ready for primetime yet,
>> though, so we should stick with Howl for now.
>>
>> -Travis
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Yahoo.
>> Introducing Yahoo! Search Developer Network - Create apps using  
>> Yahoo!
>> Search APIs Find out how you can build Yahoo! directly into your own
>> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn- 
>> ostg-q22005
>> _______________________________________________
>> Xgridagent-development mailing list
>> Xgr...@li...
>> https://lists.sourceforge.net/lists/listinfo/xgridagent-development
>>
>
> -- 
> ----------------------------------
> E-Mail: Matthew W. Jones <ma...@os...>
> Date: 27-May-2005
> Time: 17:06:31
>
> http://matburt.homeunix.com
>
> This message was sent by XFMail
> ----------------------------------
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg- 
> q22005
> _______________________________________________
> Xgridagent-development mailing list
> Xgr...@li...
> https://lists.sourceforge.net/lists/listinfo/xgridagent-development
>

I'm actually still using an old version of XGrid on Tiger (Doesn't work
as well either, it's still useable from the command line).  I'll give
the new XGrid a try this weekend.

I've noticed the issues with libHowl, I'm working on a replacement
implementation... I'll let you guys know when it's done.  Either way
1.0.3 will stay on LibHowl.

Mat

On 25-May-2005 Travis Beals wrote:
> I finally got my Xserve upgraded to Tiger, although it was hell  
> (somehow Tiger broke KDE on some of my BSD machines that NFS-mount  
> home directories from the xserve). Now, it seems that xgridagent  
> won't talk to the new controller. Matthew, are you running Tiger  
> Server successfully as a controller for a grid containing Xgridagent  
> agents? Daniel implied that this wouldn't work, and I'm inclined to  
> agree with him, although I may just have missed something. Does  
> anyone know how much work is involved in making xgridagent compatible  
> again?
> 
> As a minor consideration for future planning, it looks like there are  
> some license issues with Howl that indirectly affect us. Basically, a  
> number of linux distributions (Debian, for example) don't like the  
> patent clause in the APSL, and so won't include Howl. People can  
> always download and compile Howl themselves, but that's a bit  
> inconvenient.  See this email:
> 
> http://lists.porchdogsoft.com/pipermail/howl-users/2005-April/ 
> 000614.html
> 
> There are apparently other mDNS / ZeroConf implementations (e.g.  
> Avahi) either available or under development that do not have these  
> issues. Long-term, we should perhaps consider switching to one of  
> them. It doesn't seem that Avahi is quite ready for primetime yet,  
> though, so we should stick with Howl for now.
> 
> -Travis
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Xgridagent-development mailing list
> Xgr...@li...
> https://lists.sourceforge.net/lists/listinfo/xgridagent-development

-- 
----------------------------------
E-Mail: Matthew W. Jones <ma...@os...>
Date: 27-May-2005
Time: 17:06:31

http://matburt.homeunix.com

This message was sent by XFMail
----------------------------------

I finally got my Xserve upgraded to Tiger, although it was hell  
(somehow Tiger broke KDE on some of my BSD machines that NFS-mount  
home directories from the xserve). Now, it seems that xgridagent  
won't talk to the new controller. Matthew, are you running Tiger  
Server successfully as a controller for a grid containing Xgridagent  
agents? Daniel implied that this wouldn't work, and I'm inclined to  
agree with him, although I may just have missed something. Does  
anyone know how much work is involved in making xgridagent compatible  
again?

As a minor consideration for future planning, it looks like there are  
some license issues with Howl that indirectly affect us. Basically, a  
number of linux distributions (Debian, for example) don't like the  
patent clause in the APSL, and so won't include Howl. People can  
always download and compile Howl themselves, but that's a bit  
inconvenient.  See this email:

http://lists.porchdogsoft.com/pipermail/howl-users/2005-April/ 
000614.html

There are apparently other mDNS / ZeroConf implementations (e.g.  
Avahi) either available or under development that do not have these  
issues. Long-term, we should perhaps consider switching to one of  
them. It doesn't seem that Avahi is quite ready for primetime yet,  
though, so we should stick with Howl for now.

-Travis

> I haven't had the size problem on my Debian box since Daniel's  
> patch for
> 1.0.3, how big was the file?

The file was a little over 2.3 MB, tarred and gzip'd. Are you  
referring to 1.0.3, or some patch on top of 1.0.3? I thought the  
large files problem was supposed to be solved in 1.0.2 anyway. It  
seems that there is another issue with large files, at least on my  
BSD machines. Has anyone had success with files bigger than, say, 3  
MB (after compression), being returned by custom plug-in jobs? If so,  
what is your configuration?

> I don't think /etc is the proper place for the "agent", maybe in / 
> usr/local/etc
> or ~/.xgridagent

OK, /usr/local/etc it is.

> perhaps in your patch you could make the
> configure script generate the xgrid.config.xml

That wouldn't quite do it in terms of incorporating hostnames into  
machine IDs--there needs to be support for cluster nodes which share  
a drive, and thus also config file. We need some way of generating  
unique machine IDs for them, and hostname seems like a good option.  
There could be some flag in the config file on whether or not to  
include hostnames...

I'll be busy for a week or two with (among other things) upgrading  
machines to 10.4. After that I'll try to get on these issues.

I've been using Tiger for a little while now, and at least the publicly
available version of XGrid seems to work fine.

On 29-Apr-2005 Travis Beals wrote:

> Any ideas on this one?

I haven't had the size problem on my Debian box since Daniel's patch for
1.0.3, how big was the file?

I don't think /etc is the proper place for the "agent", maybe in /usr/local/etc
or ~/.xgridagent

Most of these seem reasonable, perhaps in your patch you could make the
configure script generate the xgrid.config.xml

-- 
----------------------------------
E-Mail: Matthew W. Jones <ma...@os...>
Date: 30-Apr-2005
Time: 01:56:00

http://matburt.homeunix.com

This message was sent by XFMail
----------------------------------

First of all, Tiger is finally out, so Daniel is now released from his 
NDA, and can tell us what's changed in Xgrid, and perhaps what we need 
to change in xgridagent to keep up.

I've found some bugs in xgridagent. There are also some subtle 
differences between xgridagent and Apple's GridAgent.

Bugs:

(1) xgridagent 1.0.3 hangs when sending large amounts of data (e.g. a 
couple MB tarred & gzipped) in the work directory back to the 
controller. Running with logging at level 4 (Debug with Beep messages), 
I see some XML that indicates a message of type 
XgMessageReplyTypeValue, named TaskFinalResults and seems to indicate 
that it contains the TarredWorkingDiretory. This is followed by about 
110 lines like this:
	04/29/05 15:18:46 [64784]  Sending frame of size 32700, size of window 
currently 181644
followed by a single line like this:
	04/29/05 15:18:46 [64784]  Sending frame of size 31186, size of window 
currently 181644
Then nothing--it hangs there. The Xgrid tachometer drops to 0, but the 
Status in the Xgrid client is "Job running". Files never are delivered 
to the client that submitted the job.
An identical job works fine on an OS X / Apple GridAgent agent, and a 
similar job with a much smaller output also works fine on a FreeBSD / 
xgridagent agent. I haven't figured out yet what the critical output 
size limit is yet, but I can work on that.

Any ideas on this one?

The following bugs are subtle differences between xgridagent and 
Apple's GridAgent

(2) Involves handling of literal parameters (and perhaps other 
parameters) in Custom Plug-ins. Suppose I create a custom plug-in that 
accepts 1 literal parameter, and passes it to a shell script. With OS X 
GridAgent, if the literal I pass has spaces (e.g. "-b 4"), it is passed 
to the shell script as a single parameter (it's stored in $1). With 
xgridagent, it's passed as two parameters.  There are also differences 
in how quotes within literals are handled.

(3) There seem to be other differences on whether stdout is returned 
with custom plugins, and whether files produced by a job are returned 
if there wasn't a working directory passed in as part of the custom 
plug-in. I will try to better characterize these differences.

Finally, I'd like to suggest the following behavior changes for 
xgridagent. Comments?

(4) xgridagent look somewhere other than current working directory for 
xgrid.config.xml (maybe /etc?)
(5) xgridagent should try to create "cookie" file somewhere other than 
current working directory (/tmp? /var/run?)
(6) Needs better support for multiple machines sharing the same 
xgrid.config.xml file. Either automatically include the hostname in the 
agentName, or provide an option to specify the agentName via the 
command line at launch time, to allow xgridagent to be launched by a 
script that passes in the hostname or some other unique identifier. 
This is necessary so xgridagent can be used in a cluster situation 
where all the nodes share a common drive.

http://xgridagent.sourceforge.net

-- 
----------------------------------
E-Mail: Matthew W. Jones <ma...@os...>
Date: 28-Apr-2005
Time: 02:46:24

http://matburt.homeunix.com
http://spg.oss-institute.org

This message was sent by XFMail
----------------------------------

Made from CVS today.

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
>

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
----------------------------------

Hi Travis:

Regarding the race condition: I really don't know.  However, I know for 
a fact that the Gnome network IO library is missing a SEQ frame 
completely when the problem occurs (the callback does not even get 
called back, although tcpflow shows the packet was sent). That looks 
quite low-level to me and I don't know enough about it to actually fix 
it.  As long as the workaround works, I'll leave it at that.  I noticed 
that some other routines in Roadrunner would run into the same pitfall 
if they were passed large amount of data, so I suspect the roadrunner 
people did not see this problem at all, therefore it would be hard for 
me/us to fix it.

sem_open() and sem_init() appear to be two means to initialize a 
thread.  I don't know a lot about threads especially their variations 
between OSes. Although this isn't the best way to do it, one could 
define a #if FREEBSD #elif DARWIN ... etc.... through autoconf (which I 
don't know well incidentally).  It's better however to go by 
functionality rather than by platform (so other new platforms are 
automatically supported in the future). I'll try to look for something 
in autoconf, but I tried at the time I implemented it and couldn't find 
anything.  Maybe some newsgroup search could help.  However, Travis 
you'll have to do the work one way or another since you have the 
FreeBSD system.

Daniel

On Apr 15, 2005, at 7:08 PM, Travis Beals wrote:

> Thanks to Daniel for putting 1.0.3 online, and for the continued work 
> on the "large files" problem. Daniel, do you think the problem is due 
> to some sort of race condition in/with Roadrunner? I'm trying to get a 
> better handle on what's going on.
>
> I finally got XGridAgent working on my FreeBSD 5.2.1 systems. It 
> turned out to be something simple--the calls to sem_open() in 
> xgridagent.c (lines 93 and 925 in the latest version on CVS) were the 
> cause of the "bad system call". Commenting those lines out to force it 
> to use sem_init() fixes the problem.
>
> From what I've read, POSIX semaphore support in FreeBSD is new as of 
> 5.0, and is somewhat buggy. I'm not sure why I'm encountering this 
> problem but Matthew isn't (differences in how we compiled our 
> kernels?), but I suspect it may be something we have to write a 
> work-around for. Here's a discussion of the sem_open / bad system call 
> problem:
>
> http://www.atm.tut.fi/list-archive/freebsd-stable/msg10083.html
>
> What approach should we take to dealing with this problem? It seems 
> like it would be fairly simple to test for it at "configure" time, 
> then fix it with appropriate preprocessor macros that force the use of 
> sem_init instead of sem_open. Unfortunately, I know next to nothing 
> about the autoconf / automake system. If someone knows of a good 
> starting point for this, I would appreciate it (of course, I would 
> appreciate it even more if someone did the work for me :-)
>
> -Travis
>

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
----------------------------------

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
----------------------------------

Thanks to Daniel for putting 1.0.3 online, and for the continued work 
on the "large files" problem. Daniel, do you think the problem is due 
to some sort of race condition in/with Roadrunner? I'm trying to get a 
better handle on what's going on.

I finally got XGridAgent working on my FreeBSD 5.2.1 systems. It turned 
out to be something simple--the calls to sem_open() in xgridagent.c 
(lines 93 and 925 in the latest version on CVS) were the cause of the 
"bad system call". Commenting those lines out to force it to use 
sem_init() fixes the problem.

 From what I've read, POSIX semaphore support in FreeBSD is new as of 
5.0, and is somewhat buggy. I'm not sure why I'm encountering this 
problem but Matthew isn't (differences in how we compiled our 
kernels?), but I suspect it may be something we have to write a 
work-around for. Here's a discussion of the sem_open / bad system call 
problem:

http://www.atm.tut.fi/list-archive/freebsd-stable/msg10083.html

What approach should we take to dealing with this problem? It seems 
like it would be fairly simple to test for it at "configure" time, then 
fix it with appropriate preprocessor macros that force the use of 
sem_init instead of sem_open. Unfortunately, I know next to nothing 
about the autoconf / automake system. If someone knows of a good 
starting point for this, I would appreciate it (of course, I would 
appreciate it even more if someone did the work for me :-)

-Travis

xgridagent-development Mailing List for XGridAgent

xgridagent-development — Development of the Unix xgrid agent for Unix operating systems.