Re: SVN commit 0.102.12

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

torbenh
On Thu, Jun 08, 2006 at 01:31:32PM -0400, Lee Revell wrote:

> On Thu, 2006-06-08 at 10:34 -0500, Jack O'Quin wrote:
> > On 6/8/06, Alfons Adriaensen <[hidden email]> wrote:
> > > On Thu, Jun 08, 2006 at 10:02:48AM -0500, Jack O'Quin wrote:
> > >
> > > > The only reason we used /tmp for so long was that we can be
> > > > certain that it exists on every system.  I suppose we could test
> > > > for the existence of /dev/shm on the *build* machine, but that
> > > > does not necessarily prove it will be present on the *install*
> > > > system.
> > >
> > > What would be wrong with testing for /dev/shm at run time ?
> > > It doesn't take so much code ...
> >
> > I suppose we could.  That would still amount to changing the
> > default.  If it's not there or not accessible, we could fall back to
> > using /tmp, I guess.  There should be a prominent error message
> > if that occurs.
>
> I wonder if "/dev/shm must exist and be a tmpfs" is part of any Linux
> desktop standard.  If not it probably should be.

at least man shm_open says:

       The POSIX shared memory object implementation on Linux 2.4 makes
       use of a dedicated file system, which is normally mounted under
       /dev/shm.

>
> Lee
>
>
>
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel
>

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Jack O'Quin
On 6/8/06, [hidden email] <[hidden email]> wrote:

> On Thu, Jun 08, 2006 at 01:31:32PM -0400, Lee Revell wrote:
> > On Thu, 2006-06-08 at 10:34 -0500, Jack O'Quin wrote:
> > > On 6/8/06, Alfons Adriaensen <[hidden email]> wrote:
> > > > On Thu, Jun 08, 2006 at 10:02:48AM -0500, Jack O'Quin wrote:
> > > >
> > > > > The only reason we used /tmp for so long was that we can be
> > > > > certain that it exists on every system.  I suppose we could test
> > > > > for the existence of /dev/shm on the *build* machine, but that
> > > > > does not necessarily prove it will be present on the *install*
> > > > > system.
> > > >
> > > > What would be wrong with testing for /dev/shm at run time ?
> > > > It doesn't take so much code ...
> > >
> > > I suppose we could.  That would still amount to changing the
> > > default.  If it's not there or not accessible, we could fall back to
> > > using /tmp, I guess.  There should be a prominent error message
> > > if that occurs.
> >
> > I wonder if "/dev/shm must exist and be a tmpfs" is part of any Linux
> > desktop standard.  If not it probably should be.
>
> at least man shm_open says:
>
>        The POSIX shared memory object implementation on Linux 2.4 makes
>        use of a dedicated file system, which is normally mounted under
>        /dev/shm.

Yes.  I think this is why most distributions now include it.

Note that JACK does *not* work if you select *both* POSIX shm and
/dev/shm for the tmpdir.  They interfere with each other.
--
 joq


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Junichi Uekawa

Hi,

> > > > > > The only reason we used /tmp for so long was that we can be
> > > > > > certain that it exists on every system.  I suppose we could test
> > > > > > for the existence of /dev/shm on the *build* machine, but that
> > > > > > does not necessarily prove it will be present on the *install*
> > > > > > system.
> > > > >
> > > > > What would be wrong with testing for /dev/shm at run time ?
> > > > > It doesn't take so much code ...
> > > >
> > > > I suppose we could.  That would still amount to changing the
> > > > default.  If it's not there or not accessible, we could fall back to
> > > > using /tmp, I guess.  There should be a prominent error message
> > > > if that occurs.
> > >
> > > I wonder if "/dev/shm must exist and be a tmpfs" is part of any Linux
> > > desktop standard.  If not it probably should be.
> >
> > at least man shm_open says:
> >
> >        The POSIX shared memory object implementation on Linux 2.4 makes
> >        use of a dedicated file system, which is normally mounted under
> >        /dev/shm.
>
> Yes.  I think this is why most distributions now include it.
>
> Note that JACK does *not* work if you select *both* POSIX shm and
> /dev/shm for the tmpdir.  They interfere with each other.

Would something like this work better?

glibc-2.3.6/nptl/sem_open.c:

/* Determine where the shmfs is mounted (if at all).  */
void
attribute_hidden
__where_is_shmfs (void)
{
  char buf[512];
  struct statfs f;
  struct mntent resmem;
  struct mntent *mp;
  FILE *fp;

  /* The canonical place is /dev/shm.  This is at least what the
     documentation tells everybody to do.  */
  if (__statfs (defaultmount, &f) == 0 && f.f_type == SHMFS_SUPER_MAGIC)
    {
      /* It is in the normal place.  */
      mountpoint.dir = (char *) defaultdir;
      mountpoint.dirlen = sizeof (defaultdir) - 1;

      return;
    }

  /* OK, do it the hard way.  Look through the /proc/mounts file and if
     this does not exist through /etc/fstab to find the mount point.  */
  fp = __setmntent ("/proc/mounts", "r");
  if (__builtin_expect (fp == NULL, 0))
    {
      fp = __setmntent (_PATH_MNTTAB, "r");
      if (__builtin_expect (fp == NULL, 0))
        /* There is nothing we can do.  Blind guesses are not helpful.  */
        return;
    }

  /* Now read the entries.  */
  while ((mp = __getmntent_r (fp, &resmem, buf, sizeof buf)) != NULL)
    /* The original name is "shm" but this got changed in early Linux
       2.4.x to "tmpfs".  */
    if (strcmp (mp->mnt_type, "tmpfs") == 0
        || strcmp (mp->mnt_type, "shm") == 0)
      {
        /* Found it.  There might be more than one place where the
           filesystem is mounted but one is enough for us.  */
        size_t namelen;

        /* First make sure this really is the correct entry.  At least
           some versions of the kernel give wrong information because
           of the implicit mount of the shmfs for SysV IPC.  */
        if (__statfs (mp->mnt_dir, &f) != 0 || f.f_type != SHMFS_SUPER_MAGIC)
          continue;

        namelen = strlen (mp->mnt_dir);

        if (namelen == 0)
          /* Hum, maybe some crippled entry.  Keep on searching.  */
          continue;

        mountpoint.dir = (char *) malloc (namelen + 4 + 2);
        if (mountpoint.dir != NULL)
          {
            char *cp = __mempcpy (mountpoint.dir, mp->mnt_dir, namelen);
            if (cp[-1] != '/')
              *cp++ = '/';
            cp = stpcpy (cp, "sem.");
            mountpoint.dirlen = cp - mountpoint.dir;
          }

        break;
      }

  /* Close the stream.  */
  __endmntent (fp);
}




regards,
        junichi
--
dancer@{debian.org,netfort.gr.jp}   Debian Project


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Marc-Olivier Barre-2
I like the idea, but if we this at runtime, we also need a good command line parameter to specify the directory we like most --> it's easier than to parse fstab, and at least we have control over what shm will be used (not just taking the first one found)
 

Would something like this work better?

glibc-2.3.6/nptl/sem_open.c:

/* Determine where the shmfs is mounted (if at all).  */
void
attribute_hidden
__where_is_shmfs (void)
{
  char buf[512];
  struct statfs f;
  struct mntent resmem;
  struct mntent *mp;
  FILE *fp;

  /* The canonical place is /dev/shm.  This is at least what the
     documentation tells everybody to do.  */
  if (__statfs (defaultmount, &f) == 0 && f.f_type == SHMFS_SUPER_MAGIC)
    {
      /* It is in the normal place.  */
      mountpoint.dir = (char *) defaultdir;
      mountpoint.dirlen = sizeof (defaultdir) - 1;

      return;
    }

  /* OK, do it the hard way.  Look through the /proc/mounts file and if
     this does not exist through /etc/fstab to find the mount point.  */
  fp = __setmntent ("/proc/mounts", "r");
  if (__builtin_expect (fp == NULL, 0))
    {
      fp = __setmntent (_PATH_MNTTAB, "r");
      if (__builtin_expect (fp == NULL, 0))
        /* There is nothing we can do.  Blind guesses are not helpful.  */
        return;
    }

  /* Now read the entries.  */
  while ((mp = __getmntent_r (fp, &resmem, buf, sizeof buf)) != NULL)
    /* The original name is "shm" but this got changed in early Linux
       2.4.x to "tmpfs".  */
    if (strcmp (mp->mnt_type, "tmpfs") == 0
        || strcmp (mp->mnt_type, "shm") == 0)
      {
        /* Found it.  There might be more than one place where the
           filesystem is mounted but one is enough for us.  */
        size_t namelen;

        /* First make sure this really is the correct entry.  At least
           some versions of the kernel give wrong information because
           of the implicit mount of the shmfs for SysV IPC.  */
        if (__statfs (mp->mnt_dir, &f) != 0 || f.f_type != SHMFS_SUPER_MAGIC)
          continue;
        namelen = strlen (mp->mnt_dir);

        if (namelen == 0)
          /* Hum, maybe some crippled entry.  Keep on searching.  */
          continue;

        mountpoint.dir = (char *) malloc (namelen + 4 + 2);
        if (mountpoint.dir != NULL)
          {
            char *cp = __mempcpy (mountpoint.dir, mp->mnt_dir, namelen);
            if (cp[-1] != '/')
              *cp++ = '/';
            cp = stpcpy (cp, "sem.");
            mountpoint.dirlen = cp - mountpoint.dir;
          }

        break;
      }

  /* Close the stream.  */
  __endmntent (fp);
}




regards,
        junichi
--
dancer@{debian.org,netfort.gr.jp}   Debian Project


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel



--
Marc-Olivier Barre.

_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Jack O'Quin
On 6/10/06, Marc-Olivier Barre <[hidden email]> wrote:
>
> I like the idea, but if we this at runtime, we also need a good command line
> parameter to specify the directory we like most --> it's easier than to
> parse fstab, and at least we have control over what shm will be used (not
> just taking the first one found)

Interesting ideas.

Don't forget that whatever groping around we do while looking for the
right tmpdir has to work identically in jackd and all of its clients.
Identifying the tmpdir is the first step in establishing communication
between all those processes.  For example, /etc/fstab could change
between the time jackd starts and some client later in the day.
--
 joq


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Lee Revell
On Sat, 2006-06-10 at 08:51 -0500, Jack O'Quin wrote:

> On 6/10/06, Marc-Olivier Barre <[hidden email]> wrote:
> >
> > I like the idea, but if we this at runtime, we also need a good command line
> > parameter to specify the directory we like most --> it's easier than to
> > parse fstab, and at least we have control over what shm will be used (not
> > just taking the first one found)
>
> Interesting ideas.
>
> Don't forget that whatever groping around we do while looking for the
> right tmpdir has to work identically in jackd and all of its clients.
> Identifying the tmpdir is the first step in establishing communication
> between all those processes.  For example, /etc/fstab could change
> between the time jackd starts and some client later in the day.

Don't parse fstab, parse /proc/mounts.

Lee



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Marc-Olivier Barre-2


Don't parse fstab, parse /proc/mounts.


My bad... I meant /proc/mounts, not fstab of course, but the problem is the same. you can't automagicaly guess which tmpfs mount point the user would like to use if he has more than one. example : on my system I use udev....

here's my /proc/mounts :

rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /dev tmpfs rw 0 0
/dev/hda8 /media/data ext3 rw,data=ordered 0 0
/dev/hda5 /media/ubuntu ext3 rw,data=ordered 0 0
/dev/hda7 /tmp ext2 rw,nogrpid 0 0
devpts /dev/pts devpts rw 0 0
shm /dev/shm tmpfs rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0

if you just use the first tmpfs found, you end up using /dev direcly. it's harmless, but I wouldn't want to see that on my system.

--
Marc-Olivier Barre,
Kinoko en Orbite.


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Lee Revell
On Sat, 2006-06-10 at 20:20 +0200, Marc-Olivier Barre wrote:

> rootfs / rootfs rw 0 0
> /dev/root / ext3 rw,data=ordered 0 0
> proc /proc proc rw 0 0
> sysfs /sys sysfs rw 0 0
> tmpfs /dev tmpfs rw 0 0
> /dev/hda8 /media/data ext3 rw,data=ordered 0 0
> /dev/hda5 /media/ubuntu ext3 rw,data=ordered 0 0
> /dev/hda7 /tmp ext2 rw,nogrpid 0 0
> devpts /dev/pts devpts rw 0 0
> shm /dev/shm tmpfs rw 0 0
> usbfs /proc/bus/usb usbfs rw 0 0
>
> if you just use the first tmpfs found, you end up using /dev direcly.
> it's harmless, but I wouldn't want to see that on my system.
>

I think we should try /dev/shm first, then /tmp if it's a tmpfs, then
give up.

Is it correct that no one has yet been able to produce an example of a
distro where /dev/shm is not a tmpfs?

Lee




_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Paul Davis
On Sat, 2006-06-10 at 14:27 -0400, Lee Revell wrote:

> On Sat, 2006-06-10 at 20:20 +0200, Marc-Olivier Barre wrote:
> > rootfs / rootfs rw 0 0
> > /dev/root / ext3 rw,data=ordered 0 0
> > proc /proc proc rw 0 0
> > sysfs /sys sysfs rw 0 0
> > tmpfs /dev tmpfs rw 0 0
> > /dev/hda8 /media/data ext3 rw,data=ordered 0 0
> > /dev/hda5 /media/ubuntu ext3 rw,data=ordered 0 0
> > /dev/hda7 /tmp ext2 rw,nogrpid 0 0
> > devpts /dev/pts devpts rw 0 0
> > shm /dev/shm tmpfs rw 0 0
> > usbfs /proc/bus/usb usbfs rw 0 0
> >
> > if you just use the first tmpfs found, you end up using /dev direcly.
> > it's harmless, but I wouldn't want to see that on my system.
> >
>
> I think we should try /dev/shm first, then /tmp if it's a tmpfs, then
> give up.
>
> Is it correct that no one has yet been able to produce an example of a
> distro where /dev/shm is not a tmpfs?

just as a footnote, i think that this approach is promising, but that it
should be a 1.0 stopgap measure before we switch to semaphores or
futexes or some other FS-independent mechanism post-1.0. the OS X
version doesn't have this issue because it uses Mach ports for
communication, and it would be nice for the linux version to do
something similar. i know that fons and possibly stephane too have done
some benchmarking of sem_post and friends and they seem fast.

that is not a 1.0 change, however. i think.

--p




_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Junichi Uekawa
In reply to this post by Jack O'Quin
Hi,

> > I like the idea, but if we this at runtime, we also need a good command line
> > parameter to specify the directory we like most --> it's easier than to
> > parse fstab, and at least we have control over what shm will be used (not
> > just taking the first one found)
>
> Interesting ideas.
>
> Don't forget that whatever groping around we do while looking for the
> right tmpdir has to work identically in jackd and all of its clients.
> Identifying the tmpdir is the first step in establishing communication
> between all those processes.  For example, /etc/fstab could change
> between the time jackd starts and some client later in the day.

Note that the case is the same with glibc.

glibc does this:

1. statfs /dev/shm/ and check if it's tmpfs, if it is, use that path.

2. looks into /proc/mounts to find tmpfs using getmntent(), and
   use the first entry.


regards,
        junichi
--
dancer@{debian.org,netfort.gr.jp}   Debian Project


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Lee Revell
In reply to this post by Paul Davis
On Sat, 2006-06-10 at 14:31 -0400, Paul Davis wrote:
> just as a footnote, i think that this approach is promising, but that
> it should be a 1.0 stopgap measure before we switch to semaphores or
> futexes or some other FS-independent mechanism post-1.0. the OS X
> version doesn't have this issue because it uses Mach ports for
> communication, and it would be nice for the linux version to do
> something similar. i know that fons and possibly stephane too have
> done some benchmarking of sem_post and friends and they seem fast.
>
> that is not a 1.0 change, however. i think.

Paul,

Post 1.0, is there any reason JACK cannot use POSIX process shared
mutexes for synchronization?

http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/da76467abe1d4713/f07a58dff177b394%23f07a58dff177b394

Lee



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Lee Revell
On Sat, 2006-06-10 at 14:54 -0400, Lee Revell wrote:

> On Sat, 2006-06-10 at 14:31 -0400, Paul Davis wrote:
> > just as a footnote, i think that this approach is promising, but that
> > it should be a 1.0 stopgap measure before we switch to semaphores or
> > futexes or some other FS-independent mechanism post-1.0. the OS X
> > version doesn't have this issue because it uses Mach ports for
> > communication, and it would be nice for the linux version to do
> > something similar. i know that fons and possibly stephane too have
> > done some benchmarking of sem_post and friends and they seem fast.
> >
> > that is not a 1.0 change, however. i think.
>
> Paul,
>
> Post 1.0, is there any reason JACK cannot use POSIX process shared
> mutexes for synchronization?
>
> http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/da76467abe1d4713/f07a58dff177b394%23f07a58dff177b394
>

Sorry this is the man page I was looking for (it's a Solaris doc but
applies to NPTL - unfortunately there is absolutely zero documentation
on using process shared mutexes with Linux/NPTL)

http://bama.ua.edu/cgi-bin/man-cgi?mutex_init+3THR

Lee



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Paul Davis
On Sat, 2006-06-10 at 15:02 -0400, Lee Revell wrote:

> On Sat, 2006-06-10 at 14:54 -0400, Lee Revell wrote:
> > On Sat, 2006-06-10 at 14:31 -0400, Paul Davis wrote:
> > > just as a footnote, i think that this approach is promising, but that
> > > it should be a 1.0 stopgap measure before we switch to semaphores or
> > > futexes or some other FS-independent mechanism post-1.0. the OS X
> > > version doesn't have this issue because it uses Mach ports for
> > > communication, and it would be nice for the linux version to do
> > > something similar. i know that fons and possibly stephane too have
> > > done some benchmarking of sem_post and friends and they seem fast.
> > >
> > > that is not a 1.0 change, however. i think.
> >
> > Paul,
> >
> > Post 1.0, is there any reason JACK cannot use POSIX process shared
> > mutexes for synchronization?
> >
> > http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/da76467abe1d4713/f07a58dff177b394%23f07a58dff177b394
> >
>
> Sorry this is the man page I was looking for (it's a Solaris doc but
> applies to NPTL - unfortunately there is absolutely zero documentation
> on using process shared mutexes with Linux/NPTL)

that might be because the last time i looked, they were not implemented.
they are an optional part of the POSIX pthreads spec.



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Lee Revell
On Sat, 2006-06-10 at 15:05 -0400, Paul Davis wrote:

> On Sat, 2006-06-10 at 15:02 -0400, Lee Revell wrote:
> > On Sat, 2006-06-10 at 14:54 -0400, Lee Revell wrote:
> > > Paul,
> > >
> > > Post 1.0, is there any reason JACK cannot use POSIX process shared
> > > mutexes for synchronization?
> > >
> > > http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/da76467abe1d4713/f07a58dff177b394%23f07a58dff177b394
> > >
> >
> > Sorry this is the man page I was looking for (it's a Solaris doc but
> > applies to NPTL - unfortunately there is absolutely zero documentation
> > on using process shared mutexes with Linux/NPTL)
>
> that might be because the last time i looked, they were not implemented.
> they are an optional part of the POSIX pthreads spec.

They certainly are now.  I've tried it and it works and appears to be
realtime safe.

My tests used a mmap()ed tmpfs file - one thing I'm not sure of is
whether it's possible for mutex operations to call down into FS code if
the file is not on a tmpfs.  It's a minor issue though as it seems
that /dev/shm is available everywhere.

Lee



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Paul Davis
i remember one reason why jack was written using FIFOs. those of you on
LAD have seen my rants about this before. at one time, we had "ASIO"
mode in which we could actively wait on the next interrupt from the
backend *in addition to* the end of the client process cycle. how do you
do that on efficiently on a POSIX OS where one "event" is delivered via
one mechanism (e.g. a return from poll/select) and another is delivered
via a different mechanism (e.g. a pthread condition being signalled).
the basic answer is that if you value efficiency, you cannot.

however, we have removed "ASIO" mode and so at present this objection no
longer applies. just some historical perspective. and just another
example of why i want "man wake_me_up_before_you_go_go(2)" to print
something useful :)





_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Lee Revell
On Sat, 2006-06-10 at 15:26 -0400, Paul Davis wrote:

> i remember one reason why jack was written using FIFOs. those of you on
> LAD have seen my rants about this before. at one time, we had "ASIO"
> mode in which we could actively wait on the next interrupt from the
> backend *in addition to* the end of the client process cycle. how do you
> do that on efficiently on a POSIX OS where one "event" is delivered via
> one mechanism (e.g. a return from poll/select) and another is delivered
> via a different mechanism (e.g. a pthread condition being signalled).
> the basic answer is that if you value efficiency, you cannot.
>
> however, we have removed "ASIO" mode and so at present this objection no
> longer applies. just some historical perspective. and just another
> example of why i want "man wake_me_up_before_you_go_go(2)" to print
> something useful :)

I once saw a port of the Win32 WaitForMultipleEvents API to Unix but it
was ugly.

Lee



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Jussi Laako
In reply to this post by Paul Davis
Paul Davis wrote:
>>> Post 1.0, is there any reason JACK cannot use POSIX process shared
>>> mutexes for synchronization?
>
> that might be because the last time i looked, they were not implemented.
> they are an optional part of the POSIX pthreads spec.

Those are implemented in NPTL. Any reasonably recent glibc contains
support for _PSHARED flag. I've successfully used those for
mutex/condition etc for over two years now.


        - Jussi


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Jussi Laako
In reply to this post by Paul Davis
Paul Davis wrote:
> do that on efficiently on a POSIX OS where one "event" is delivered via
> one mechanism (e.g. a return from poll/select) and another is delivered
> via a different mechanism (e.g. a pthread condition being signalled).
> the basic answer is that if you value efficiency, you cannot.

Both could send a message to same message queue, for example. Both can
also signal the same condition variable.


        - Jussi


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN commit 0.102.12

Paul Davis
On Sat, 2006-06-10 at 23:00 +0300, Jussi Laako wrote:
> Paul Davis wrote:
> > do that on efficiently on a POSIX OS where one "event" is delivered via
> > one mechanism (e.g. a return from poll/select) and another is delivered
> > via a different mechanism (e.g. a pthread condition being signalled).
> > the basic answer is that if you value efficiency, you cannot.
>
> Both could send a message to same message queue, for example. Both can
> also signal the same condition variable.

but "they" do not send messages to any queue - that would require 1
thread per "event type", which is basically an ugly hack that i can see
no reason to require in a modern operating system. the AIX kqueue system
gets a little closer to what is desirable, but its not POSIX.




_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel