Re: Issue with pth_mutex_acquire.
On Fri, Oct 08, 2004 at 10:03:50PM +0530, Vinu V wrote: > > Thanks Jason for the reply. > > But why is this considered not safe. Could this be a little more elaborated ? Asynchronous signal handlers can be executed at any time. This means that you could be part way through locking a mutex in normal (non-signal handler) code, then jump into the signal handler. You might succeed in locking the mutex in the signal handler, but the normal code assumed that the mutex lock operation was atomic, and the signal handler has gone and messed with the mutex behind the normal code's back. Havoc ensues. Pth does not protect against signal handlers in such critical sections of code (mutex locking in this example), because the overhead would be prohibitively expensive. It is your responsibility not to do anything dangerous in the signal handler. In general, threads and signals do not mix well. In practice, it s often necessary to use both, but doing so is a delicate dance. You would be well advised to read a book that covers this issue in some detail. My favorite is "Programming with POSIX Threads", by David Butenhof. Jason __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ Development Site http://www.ossp.org/pkg/lib/pth/ Distribution Files ftp://ftp.gnu.org/gnu/pth/ Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Re: Issue with pth_mutex_acquire.
On Fri, Oct 08, 2004 at 09:27:57PM +0530, Vinu V wrote: > > Hi, > > I am having some problem in using linux signals with Pth threads. > > This is what I have done > > 1. From the main (), I have done a pth_init (). > 2. Spawned two threads from the main(). These two threads just runs in a > while loop with a small delay inside the while loop. > 3. Registered a signal handler for SIGUSR1 signal from main(). I am using > sigaction() system call for registering the signal handler. > 4. main() does a pth_join() on the child thread ids. > > Now from the signal handler for SIGUSR1 I am trying to acquire a mutex > using the pth_mutex_acquire() call. > Whenever the signal handler is executed, the program crashes at the > pth_mutex_acquire() call. > > Does anyone have any idea about why it is crashing while trying to acquire > a mutex from a signal handler ? What you can safely call in a signal handler is extremely limited. Mutex acquisition is definitely not on the list of safe APIs. Jason __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ Development Site http://www.ossp.org/pkg/lib/pth/ Distribution Files ftp://ftp.gnu.org/gnu/pth/ Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Re: Line-oriented blocking input from sockets?
On Sun, Jul 13, 2003 at 05:41:14PM -0700, Damon Hastings wrote: > > If the context-switching overhead turns out to be too high, then I will do > exactly that. But it will mean maintaining state for each connection, and > that state will only grow more complex with future enhancements by myself > and others. The big draw to Pth for me is the simplicity of threaded code > with the efficiency of a state machine. At least, I think it will be > efficient. I don't actually know at this point exactly how expensive a > context-switch in Pth is. Keep in mind that each thread still has its own stack, which can be a lot of overhead as the number of threads grows. You mentioned connection state complexity rather than size, so maybe this isn't a concern for you. Jason __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ Development Site http://www.ossp.org/pkg/lib/pth/ Distribution Files ftp://ftp.gnu.org/gnu/pth/ Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Re: [ANNOUNCE] GNU Pth 2.0b1
On Fri, Nov 08, 2002 at 09:36:52PM +0100, Ralf S. Engelschall wrote: > Thanks for your feedback. Even more integrated fixes and changes now > await our testing. After mostly rewriting pth_poll(3) and pth_select(3) > in order to be more POSIX.1-2001/SUSv3 compliant we all should give it a > try before proceeding with other changes, so I've rolled version 2.0b1. > Give it a try, please. I ran Pth 2.0b1 through my test suite over the weekend, and did not find any problems. Jason __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Re: [ANNOUNCE] GNU Pth 2.0b0 (beta version)
On Thu, Nov 07, 2002 at 05:13:58PM +0100, Ralf S. Engelschall wrote: > After integrating lots of pending bugfixes and enhancements into > the official GNU Pth source tree I've rolled an official 2.0b0 > version which is available from the OSSP project environment > under http://www.ossp.org/pkg/lib/pth/. Fetch the tarball from: > ftp://ftp.ossp.org/pkg/lib/pth/pth-2.0b0.tar.gz The complete ChangeLog > you can find under http://cvs.ossp.org/pkg/lib/pth/ChangeLog. Please > give feedback to make GNU Pth 2.0 as good as it can be. I built pth as such: ./configure --enable-syscall-hard make make test make install It appears that pth now has a dependency on libdl (specifically dlopen(), dlsym(), and dlclose()), and `pth-config --libs` does not specify -ldl. Jason __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Re: Is someone maintaining pth?
On Tue, Aug 27, 2002 at 01:59:21PM -0700, Archie Cobbs wrote: > Jason Evans wrote: > > On Tue, Jul 30, 2002 at 08:29:53PM +0200, Ralf S. Engelschall wrote: > > > In case there are still any problems and/or patches around > > > we still have not included into the CVS state of Pth (see > > > http://cvs.ossp.org/pkg/lib/pth/), please do not hesitate to repost them > > > here again. Perhaps they were just lost or overlooked. I'll try to > > > make sure they are considered again. > > > > Following is a patch that I posted, and it has not been committed. As > > noted in its explanation, it may not suite the needs of the maintainers, > > but if you provide some feedback, I'm perfectly willing to do the work to > > make it acceptable. > > Hello Ralf and the list, > > I would like to kindly point out that there has been no response > whatsoever (that I've seen) to Jason's email sent back on June 30, > nor have the changes been incorporated into pth (according to the > http://cvs.ossp.org/pkg/lib/pth/). > > This is somewhat ironic, given this particular thread... I also sent email directly to Ralf, and heard no response from that either. As things stand, I can't help but form the grudging opionion that pth is being squatted on. Pretending to maintain a project without actually doing so is worse than doing nothing at all, since it discourages others from filling the void. Jason __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Re: Is someone maintaining pth?
On Tue, Jul 30, 2002 at 08:29:53PM +0200, Ralf S. Engelschall wrote:
>
> In case there are still any problems and/or patches around
> we still have not included into the CVS state of Pth (see
> http://cvs.ossp.org/pkg/lib/pth/), please do not hesitate to repost them
> here again. Perhaps they were just lost or overlooked. I'll try to
> make sure they are considered again.
Following is a patch that I posted, and it has not been committed. As
noted in its explanation, it may not suite the needs of the maintainers,
but if you provide some feedback, I'm perfectly willing to do the work to
make it acceptable.
Thanks,
Jason
--
Date: Sat, 22 Jun 2002 16:38:18 -0700
From: Jason Evans <[EMAIL PROTECTED]>
Subject: Problems with poll()
To: [EMAIL PROTECTED]
pth_poll_ev() does not provide any support for POLLRDNORM, POLLWRNORM,
POLLRDBAND, or POLLWRBAND. This causes surprising errors when calling
poll(), if pth is configured with the --enable-syscall-hard flag. The
following patch is adequate to support the additional poll() flags, but it
still does not solve the whole problem. On Linux, it is necessary to
define _GNU_SOURCE or _XOPEN_SOURCE (other definitions may also work) in
order for the additional poll() flags to be exposed. This means that pth
should probably always be built with _XOPEN_SOURCE on Linux, so that if an
application chooses to use the additional poll() flags, pth is able to
accomodate the application. Always building pth like this won't hurt
anything in the case that the application does not know about the
additional poll() flags.
A patch for the pth_poll_ev() problems follows.
Thanks,
Jason Evans
--- pth-1.4.1.old/pth_high.cSun Jan 27 05:14:36 2002
+++ pth-1.4.1/pth_high.cSat Jun 22 16:18:12 2002
@@ -413,13 +413,42 @@
for(i = 0; i < nfd; i++) {
if (!pth_util_fd_valid(pfd[i].fd))
return_errno(-1, EBADF);
-if (pfd[i].events & POLLIN)
+if (pfd[i].events & (POLLIN
+#ifdef POLLRDNORM
+| POLLRDNORM
+#endif
+))
FD_SET(pfd[i].fd, &rfds);
-if (pfd[i].events & POLLOUT)
+if (pfd[i].events & (POLLOUT
+#ifdef POLLWRNORM
+| POLLWRNORM
+#endif
+#ifdef POLLWRBAND
+| POLLWRBAND
+#endif
+))
FD_SET(pfd[i].fd, &wfds);
-if (pfd[i].events & POLLPRI)
+if (pfd[i].events & (POLLPRI
+#ifdef POLLRDBAND
+| POLLRDBAND
+#endif
+))
FD_SET(pfd[i].fd, &efds);
-if (pfd[i].fd >= maxfd && (pfd[i].events & (POLLIN|POLLOUT|POLLPRI)))
+if (pfd[i].fd >= maxfd && (pfd[i].events & (POLLIN|POLLOUT|POLLPRI
+#ifdef POLLRDNORM
+ | POLLRDNORM
+#endif
+#ifdef POLLWRNORM
+ | POLLWRNORM
+#endif
+#ifdef POLLWRBAND
+ | POLLWRBAND
+#endif
+#ifdef POLLRDBAND
+ | POLLRDBAND
+#endif
+
+ )))
maxfd = pfd[i].fd;
}
if (maxfd == -1)
@@ -439,7 +468,12 @@
continue;
}
if (FD_ISSET(pfd[i].fd, &rfds)) {
-pfd[i].revents |= POLLIN;
+ if (pfd[i].events & POLLIN)
+ pfd[i].revents |= POLLIN;
+#ifdef POLLRDNORM
+ if (pfd[i].events & POLLRDNORM)
+ pfd[i].revents |= POLLRDNORM;
+#endif
ok++;
/* support for POLLHUP */
if (recv(pfd[i].fd, data, 64, MSG_PEEK) == -1) {
@@ -452,11 +486,25 @@
}
}
if (FD_ISSET(pfd[i].fd, &wfds)) {
-pfd[i].revents |= POLLOUT;
+ if (pfd[i].events & POLLOUT)
+ pfd[i].revents |= POLLOUT;
+#ifdef POLLWRNORM
+ if (pfd[i].events & POLLWRNORM)
+ pfd[i].revents |= POLLWRNORM;
+#endif
+#ifdef POLLWRBAND
+ if (pfd[i].events & POLLWRBAND)
+ pfd[i].revents |= POLLWRBAND;
+#endif
ok++;
}
if (FD_ISSET(pfd[i].fd, &efds)) {
-pfd[i].revents |= POLLPRI;
+ if (pfd[i].events & POLLPRI)
+ pfd[i].revents |= POLLPRI;
+#ifdef POLLRDBAND
+ if (pfd[i].events & POLLRDBAND)
+ pfd[i].revents |= POLLRDBAND;
+#endif
ok++;
}
if (ok)
__
GNU Portable Threads (Pth)http://www.gnu.org/software/pth/
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
Is someone maintaining pth?
I've been subscribed to this list for several weeks now, and have seen no indication that someone is actually maintaining pth. There have been at least 4 bug reports, 3 of which included fixes. I'd like to know if someone is keeping track of all the fixes people are providing, since I recently added pth support to a piece of software I wrote. Jason __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Problems with poll()
pth_poll_ev() does not provide any support for POLLRDNORM, POLLWRNORM,
POLLRDBAND, or POLLWRBAND. This causes surprising errors when calling
poll(), if pth is configured with the --enable-syscall-hard flag. The
following patch is adequate to support the additional poll() flags, but it
still does not solve the whole problem. On Linux, it is necessary to
define _GNU_SOURCE or _XOPEN_SOURCE (other definitions may also work) in
order for the additional poll() flags to be exposed. This means that pth
should probably always be built with _XOPEN_SOURCE on Linux, so that if an
application chooses to use the additional poll() flags, pth is able to
accomodate the application. Always building pth like this won't hurt
anything in the case that the application does not know about the
additional poll() flags.
A patch for the pth_poll_ev() problems follows.
Thanks,
Jason Evans
--- pth-1.4.1.old/pth_high.cSun Jan 27 05:14:36 2002
+++ pth-1.4.1/pth_high.cSat Jun 22 16:18:12 2002
@@ -413,13 +413,42 @@
for(i = 0; i < nfd; i++) {
if (!pth_util_fd_valid(pfd[i].fd))
return_errno(-1, EBADF);
-if (pfd[i].events & POLLIN)
+if (pfd[i].events & (POLLIN
+#ifdef POLLRDNORM
+| POLLRDNORM
+#endif
+))
FD_SET(pfd[i].fd, &rfds);
-if (pfd[i].events & POLLOUT)
+if (pfd[i].events & (POLLOUT
+#ifdef POLLWRNORM
+| POLLWRNORM
+#endif
+#ifdef POLLWRBAND
+| POLLWRBAND
+#endif
+))
FD_SET(pfd[i].fd, &wfds);
-if (pfd[i].events & POLLPRI)
+if (pfd[i].events & (POLLPRI
+#ifdef POLLRDBAND
+| POLLRDBAND
+#endif
+))
FD_SET(pfd[i].fd, &efds);
-if (pfd[i].fd >= maxfd && (pfd[i].events & (POLLIN|POLLOUT|POLLPRI)))
+if (pfd[i].fd >= maxfd && (pfd[i].events & (POLLIN|POLLOUT|POLLPRI
+#ifdef POLLRDNORM
+ | POLLRDNORM
+#endif
+#ifdef POLLWRNORM
+ | POLLWRNORM
+#endif
+#ifdef POLLWRBAND
+ | POLLWRBAND
+#endif
+#ifdef POLLRDBAND
+ | POLLRDBAND
+#endif
+
+ )))
maxfd = pfd[i].fd;
}
if (maxfd == -1)
@@ -439,7 +468,12 @@
continue;
}
if (FD_ISSET(pfd[i].fd, &rfds)) {
-pfd[i].revents |= POLLIN;
+ if (pfd[i].events & POLLIN)
+ pfd[i].revents |= POLLIN;
+#ifdef POLLRDNORM
+ if (pfd[i].events & POLLRDNORM)
+ pfd[i].revents |= POLLRDNORM;
+#endif
ok++;
/* support for POLLHUP */
if (recv(pfd[i].fd, data, 64, MSG_PEEK) == -1) {
@@ -452,11 +486,25 @@
}
}
if (FD_ISSET(pfd[i].fd, &wfds)) {
-pfd[i].revents |= POLLOUT;
+ if (pfd[i].events & POLLOUT)
+ pfd[i].revents |= POLLOUT;
+#ifdef POLLWRNORM
+ if (pfd[i].events & POLLWRNORM)
+ pfd[i].revents |= POLLWRNORM;
+#endif
+#ifdef POLLWRBAND
+ if (pfd[i].events & POLLWRBAND)
+ pfd[i].revents |= POLLWRBAND;
+#endif
ok++;
}
if (FD_ISSET(pfd[i].fd, &efds)) {
-pfd[i].revents |= POLLPRI;
+ if (pfd[i].events & POLLPRI)
+ pfd[i].revents |= POLLPRI;
+#ifdef POLLRDBAND
+ if (pfd[i].events & POLLRDBAND)
+ pfd[i].revents |= POLLRDBAND;
+#endif
ok++;
}
if (ok)
__
GNU Portable Threads (Pth)http://www.gnu.org/software/pth/
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
