[Xgridagent-development] Re: FreeBSD & sem_open Bad System Call

[<dc...@no...>]

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
>