Thomas writes:
>> when trying out uf a certain shared memory allocator would work on
>> Cygwin, I tried out the sample program below (which works on Linunx,
>> *BSD, AIX and Solaris) and got a suprising falure
> Actually, the failure wasn't all that unexpected, given that I had put the
> ftrun
> > > > > > Here is a "program" that shows the issue I am worried about. It is
> > > > > > so
> simple
> > > > > that I must be overlooking something really obvious:
> > > > > >
> > > > > > #include
> > > > > > #undef FD_SETSIZE
> > > > > > #define FD_SETSIZE 256
> > > > > > #include
> > > > > >
> >
> > Here is a "program" that shows the issue I am worried about. It is so simple
> that I must be overlooking something really obvious:
> >
> > #include
> > #undef FD_SETSIZE
> > #define FD_SETSIZE 256
> > #include
> > #include
> >
> > main()
> > {
> > fd_set rfds;
> > fprint
> >
> > There are (of course) a lot of other included files, and
> > is one of them. In my code it comes AFTER the
> > redefinition of FD_SETSIZE and . I don't think this
> > could be the issue.
>
> It is if you are mixing Windows API and Cygwin.
>
> Just look at sys/select.h and you'll under
I am running into a problem with the fd_set structure that someone may know the
answer to.
I would like to be able to call select() on more than 64 open files, so I have
done the following:
1) the include section of the program has the code:
#undef FD_SETSIZE
#define FD_SETSIZE 256
#include
We have successfully ported our software to Cygwin -- in the past we have
ported
this source code to SFU/SUA, Linux, AIX, HPUX, SCO, iSeries PASE, and OSX.
The
Cygwin port was no harder than any other port, and the result is working
really
nicely.
The Cygwin version has passed its first week of be
>
> Ok, I can reproduce it, but it's too late to debug this today.
>
> I have to say, though, that fcntl advisory locking is POSIX
> functionality, while the spawn functions are not. In fact these dreaded
> spawn entry points are rather old stuff, which hasn't been tested for a
> long time. FWI
> How do you test that? You're calling fcntl(F_SETLKW) exactly once at
> the start of your test application, but never again later. We're
> talking advisory file locking here, so, where's the next fcntl call
> waiting for the lock?
>
> I debugged your test app and the lock still exists after the
I have a simple programs that show the following issue:
1) program locks a file (in my test /tmp/yyy)
2) program then calls spawnv() (in my test"/bin/sh -c /bin/touch
/tmp/xxx").
3) after the spawnv(), the file /tmp/yyy is no longer locked.
It seems to me that this is wrong. Perhaps I am mi
> >> On 2/6/2014 8:50 AM, Steven Bardwell wrote:
> >>> Larry - thanks for the link to the source for the spawn() APIs. It
> > works
> >>> perfectly on my 32-bit install (where, as it happens, the fork() issue
> >>> never shows up either).
&g
> >> On 2/6/2014 8:50 AM, Steven Bardwell wrote:
> >>> Larry - thanks for the link to the source for the spawn() APIs. It
> > works
> >>> perfectly on my 32-bit install (where, as it happens, the fork() issue
> >>> never shows up either).
&g
> On 2/6/2014 8:50 AM, Steven Bardwell wrote:
> > Larry - thanks for the link to the source for the spawn() APIs. It
works
> > perfectly on my 32-bit install (where, as it happens, the fork() issue
> > never shows up either).
> >
> > However, on my 64-bit instal
> On Jan 30 07:25, Steven Bardwell wrote:
> > > > On 29/01/2014 19:12, Corinna Vinschen wrote:
> > > > >On Jan 29 09:00, Steven Bardwell wrote:
> > > > >>My application needs several areas of shared memory, and I am
> getting
> > > an
&
> > On 29/01/2014 19:12, Corinna Vinschen wrote:
> > >On Jan 29 09:00, Steven Bardwell wrote:
> > >>My application needs several areas of shared memory, and I am getting
> an
> > >>error ("No such device") on the second call to mmap(). The fi
> On Jan 29 09:00, Steven Bardwell wrote:
> > My application needs several areas of shared memory, and I am getting an
> > error ("No such device") on the second call to mmap(). The first call works
> > fine.
> >
> >
> > The problem does not seem t
On 1/25/2014 3:04 PM, Steven Bardwell wrote:
> I would like to understand why Cygwin style paths do not work in a CMD
(DOS)
> window on my 32-bit Cygwin system, but work fine on my 64-bit Cygwin
> install.
>
> Here is a simple example of the issue:
>
> #include
> #include
Create the directory '/dev/shm' and set the permissions to 01777.
For instance on the command line: mkdir -m 01777 /dev/shm
Steve
---
On Dec 14 08:04, Steven Bardwell wrote:
> I would like my
17 matches
Mail list logo
