Bug#753084: locales: wish it would take advantage of multiple cores
Package: locales Version: 2.19-4 Severity: wishlist The process of generating all locales takes a huge amount of time. It would be good if it could run multiple processes to take advantage of multi-core systems. Also it would be good if there was an option to generate one locale for each language. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.53 ii libc6 [glibc-2.19-1] 2.19-4 locales recommends no packages. locales suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140629051128.30992.29929.reportbug@athena
Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
I'm inclined to say libc is not the right place to fix this. If the user says write/send 0, what that means should be up to the io server to decide--even if all the servers we have today are intending to implement the same POSIX semantics. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140628190551.308052c3...@topped-with-meat.com
Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
Hi Richard, On 28.06.2014 10:48, Richard Braun wrote: Thanks for the report. There are actually two sides of the problem. First, I agree that there seems to be a bug, but let's take a closer look at the spec. The return value for recv() is defined as : "Upon successful completion, recv() shall return the length of the message in bytes. If no messages are available to be received and the peer has performed an orderly shutdown, recv() shall return 0." This doesn't creates a strict equivalence between "orderly shutdown" and "shall return 0". But in practice, this seems to be the actual assumption, so let's say that there is indeed a Hurd bug here. By the way, although the send() and recv() functions themselves (in glibc) may benefit from additions to filter out empty messages (at least send()), the server functions are those found in pflocal concerning AF_UNIX sockets. But there is also a bug in the client code, IMO. Here is how send() is specified : "The length of the message to be sent is specified by the length argument. [...] If the socket argument refers to a socket and the flags argument is 0, the send() function is equivalent to write()." And here is write() : "If nbyte is zero and the file is not a regular file, the results are unspecified." We might also want to change this though, since the behaviour observed on other systems seems more appropriate. Thanks for looking into this. Indeed, according to the specification, the behavior is unspecified. (Which IMHO is a bug in the specification.) But the specification also says: "Before any action described below is taken, and if nbyte is zero and the file is a regular file, the write() function may detect and return errors as described below. In the absence of errors, or if error detection is not performed, the write() function shall return zero and have no other results." This holds only for regular files, but the principle of least surprise suggests that it should also hold for special files, if that is possible. On 28.06.2014 11:51, Richard Braun wrote: > I've committed a fix upstream [1], please see if it solves your issues > as well. I tried this patch and with it applied both the example program and clamd/clamdscan work as they should. But I can't comment on Samuel's objections to the patch. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53aef770.6060...@googlemail.com
Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
On Sat, Jun 28, 2014 at 12:42:40PM +0200, Richard Braun wrote: > I'll see if simply catching completely empty messages at socket_send is > a good enough solution. The solution seems to work, and I couldn't see anything against it, unlike the previous attempt. However I'd really like to put it into libpipe as I don't see any need, but only potential problems, for empty data packets. I'll wait for your reply before taking action. -- Richard Braun -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140628125242.ga10...@dalaran.sceen.net
Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
On Sat, Jun 28, 2014 at 12:09:15PM +0200, Samuel Thibault wrote: > Richard Braun, le Sat 28 Jun 2014 11:51:42 +0200, a écrit : > > On Sat, Jun 28, 2014 at 10:48:56AM +0200, Richard Braun wrote: > > > On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote: > > > > This is because the client is calling: > > > > send(sockfd, "", 0, 0) > > > > > > > > Normally this doesn't trigger recv() in the server and thus can be > > > > used to test, whether the socket is working. > > > > But on Hurd it actually sends an empty message, so that the real > > > > message, which is sent later, is not received. > > > > I've committed a fix upstream [1], please see if it solves your issues > > as well. > > > > [1] > > http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=6f856c62613ffc82bf3572a372d2851638c2fb90 > > Mmm, I'm not sure we want to fix it in libpipe: other users of libpipe > may want to pass empty messages (e.g. as mere tokens). Strictly > speaking, it could be fixed in glibc's send() function. It however makes > sense to me to fix it at the socket RPC protocol, i.e. in pflocal's > S_socket_send. In addition, I just noticed that passing control data relies on always passing regular data, so this needs to be fixed too. However, I'm not sure I understand why other users would rely on a stream protocol for tokens. This would merely result in spurious wakeups, and AIUI, control data is meant exactly for that purpose. I'll see if simply catching completely empty messages at socket_send is a good enough solution. -- Richard Braun -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140628104240.ga16...@dalaran.sceen.net
Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
Richard Braun, le Sat 28 Jun 2014 11:51:42 +0200, a écrit : > On Sat, Jun 28, 2014 at 10:48:56AM +0200, Richard Braun wrote: > > On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote: > > > This is because the client is calling: > > > send(sockfd, "", 0, 0) > > > > > > Normally this doesn't trigger recv() in the server and thus can be > > > used to test, whether the socket is working. > > > But on Hurd it actually sends an empty message, so that the real > > > message, which is sent later, is not received. > > I've committed a fix upstream [1], please see if it solves your issues > as well. > > [1] > http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=6f856c62613ffc82bf3572a372d2851638c2fb90 Mmm, I'm not sure we want to fix it in libpipe: other users of libpipe may want to pass empty messages (e.g. as mere tokens). Strictly speaking, it could be fixed in glibc's send() function. It however makes sense to me to fix it at the socket RPC protocol, i.e. in pflocal's S_socket_send. Samuel -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140628100915.gz6...@type.youpi.perso.aquilenet.fr
Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
On Sat, Jun 28, 2014 at 10:48:56AM +0200, Richard Braun wrote: > On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote: > > This is because the client is calling: > > send(sockfd, "", 0, 0) > > > > Normally this doesn't trigger recv() in the server and thus can be > > used to test, whether the socket is working. > > But on Hurd it actually sends an empty message, so that the real > > message, which is sent later, is not received. > > Hello, > > Thanks for the report. There are actually two sides of the problem. > First, I agree that there seems to be a bug, but let's take a closer I've committed a fix upstream [1], please see if it solves your issues as well. -- Richard Braun [1] http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=6f856c62613ffc82bf3572a372d2851638c2fb90 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140628095142.ga7...@dalaran.sceen.net
Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote: > This is because the client is calling: > send(sockfd, "", 0, 0) > > Normally this doesn't trigger recv() in the server and thus can be > used to test, whether the socket is working. > But on Hurd it actually sends an empty message, so that the real > message, which is sent later, is not received. Hello, Thanks for the report. There are actually two sides of the problem. First, I agree that there seems to be a bug, but let's take a closer look at the spec. The return value for recv() is defined as : "Upon successful completion, recv() shall return the length of the message in bytes. If no messages are available to be received and the peer has performed an orderly shutdown, recv() shall return 0." This doesn't creates a strict equivalence between "orderly shutdown" and "shall return 0". But in practice, this seems to be the actual assumption, so let's say that there is indeed a Hurd bug here. By the way, although the send() and recv() functions themselves (in glibc) may benefit from additions to filter out empty messages (at least send()), the server functions are those found in pflocal concerning AF_UNIX sockets. But there is also a bug in the client code, IMO. Here is how send() is specified : "The length of the message to be sent is specified by the length argument. [...] If the socket argument refers to a socket and the flags argument is 0, the send() function is equivalent to write()." And here is write() : "If nbyte is zero and the file is not a regular file, the results are unspecified." We might also want to change this though, since the behaviour observed on other systems seems more appropriate. -- Richard Braun -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140628084856.ga24...@dalaran.sceen.net
