question on socket server

Hello I have little knowledge about socket programming. I have a question that, if I have made a socket server, listening on a port. The server prints data to the socket, but there is never a client connection to the port, and the data is never consumed. What will happen to the server then? will

Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

On 14.12.2021 22:00, Mark Millard wrote: > On 2021-Dec-14, at 17:35, Alexander Motin wrote: > >> On 14.12.2021 20:21, Mark Millard wrote: >>> I presume that because of FreeBSD's releng/13.0 and stable/13 (and >>> releng/13.? futures) that: >>> >>>

Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

On 2021-Dec-14, at 17:35, Alexander Motin wrote: > On 14.12.2021 20:21, Mark Millard wrote: >> I presume that because of FreeBSD's releng/13.0 and stable/13 (and >> releng/13.? futures) that: >> >> /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd >> >> will never have edonr added to the

Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

On 14.12.2021 20:21, Mark Millard wrote: > I presume that because of FreeBSD's releng/13.0 and stable/13 (and > releng/13.? futures) that: > > /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd > > will never have edonr added to the file. Sound right? FreeBSD stable/13 is tracking still alive

Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

On 2021-Dec-14, at 16:54, Alexander Motin wrote: > Mark, > > Support for edonr checksums was added to FreeBSD main about a month ago: > https://github.com/openzfs/zfs/pull/12735 . In 13 it is indeed still > not supported. But you should not worry too much about it, since even > enabled but

Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

On 2021-Dec-14, at 16:36, Mark Millard wrote: > I just noticed that main reports that my pools were created > implicitly matching openzfs-2.1-freebsd (and without > an explicit compatibility assignment) but, under main, zpool > import and zpool status for those pools report a new, disabled >

Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

Mark, Support for edonr checksums was added to FreeBSD main about a month ago: https://github.com/openzfs/zfs/pull/12735 . In 13 it is indeed still not supported. But you should not worry too much about it, since even enabled but not activated feature should not cause problems with pool import

/usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

I just noticed that main reports that my pools were created implicitly matching openzfs-2.1-freebsd (and without an explicit compatibility assignment) but, under main, zpool import and zpool status for those pools report a new, disabled feature. Turns out the issue matches what the diff below

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 03:47:17PM -0700, Warner Losh wrote: > On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > > > On 14 Dec 2021, at 21:51, Steve Kargl > > wrote: > > > Interval max ULP x at Max ULP > > > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > > >

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > On 14 Dec 2021, at 21:51, Steve Kargl > wrote: > > Interval max ULP x at Max ULP > > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > > [1.0662,6]0.861508 at 1.999467927053585410537e+00 > >

Re: What to do about tgammal?

On 14 Dec 2021, at 21:51, Steve Kargl wrote: > Interval max ULP x at Max ULP > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > [1.0662,6]0.861508 at 1.999467927053585410537e+00 > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > [-1.,-1.0001]

Re: What to do about tgammal?

> On 14 Dec 2021, at 20:41, Steve Kargl > wrote: > > On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: >> >> This is now visible for review at >> https://reviews.freebsd.org/D33444 >> > > Just looked at this again. I cannot tell from the > diff

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > I see imp lamented that that fact that he is not sufficiently versed in the numerical methods used (neither am I!). bde

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Just looked at this again. I cannot tell from the diff whether you've 'git mv' src/imprecise.c to ld128/b_tgammal.c.

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Thanks! I looks okay to me (but, of course, I wrote the patch ;-) BTW, I'll probably take a shot at ld128 tgammal(x)

Re: What to do about tgammal?

> On 13 Dec 2021, at 02:22, Steve Kargl > wrote: > > On Sat, Dec 04, 2021 at 11:48:13PM +, Mark Murray wrote: >> >> >>> On 4 Dec 2021, at 18:53, Steve Kargl >>> wrote: >>> >>> >>> So, is anyone interested in seeing a massive patch? >> >> Me, please! >> > > So, I have the ld80

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On 12/14/21 9:40 AM, Gleb Smirnoff wrote: On Tue, Dec 14, 2021 at 09:28:07AM -0800, John Baldwin wrote: J> > AFAIK, today it will always panic only with WITNESS. Without WITNESS it would J> > pass through mtx_lock as long as the mutex is not locked. J> J> Yes, but the default kernel on head is

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, Dec 14, 2021 at 09:28:07AM -0800, John Baldwin wrote: J> > AFAIK, today it will always panic only with WITNESS. Without WITNESS it would J> > pass through mtx_lock as long as the mutex is not locked. J> J> Yes, but the default kernel on head is GENERIC which has witness enabled, hence

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, Dec 14, 2021 at 09:27:01AM -0800, John Baldwin wrote: > On 12/14/21 2:14 AM, Alexey Dokuchaev wrote: > > How do you mean? Most FreeBSD people, not some random Twitter crowd, > > want the bell to be on by default, but it's still off. > > I don't know that that's true, and I myself am not

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On 12/13/21 12:25 PM, Gleb Smirnoff wrote: On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote: J> > J> So there are two things here. The root issue is that the devel/apr1 port J> > J> runs a configure test for TCP_NDELAY being inherited by accepted sockets. J> > J> This test panics

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On 12/14/21 2:14 AM, Alexey Dokuchaev wrote: How do you mean? Most FreeBSD people, not some random Twitter crowd, want the bell to be on by default, but it's still off. I don't know that that's true, and I myself am not sure that I want it back on by default. Previously my laptop had a

Re: RFC: What to do about Allocate in the NFS server for FreeBSD13?

On 12/13/21 8:30 AM, Konstantin Belousov wrote: On Mon, Dec 13, 2021 at 04:26:42PM +, Rick Macklem wrote: Hi, There are two problems with Allocate in the NFSv4.2 server in FreeBSD13: 1 - It uses the thread credentials instead of the ones for the RPC. 2 - It does not ensure that file

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, 14 Dec 2021 11:05:19 + Alexey Dokuchaev wrote: > On Tue, Dec 14, 2021 at 11:27:07AM +0100, Emmanuel Vadot wrote: > > On Tue, 14 Dec 2021 10:14:24 + Alexey Dokuchaev wrote: > > > ... > > > I know that I had problemless desktop some 10-5 years ago, okayish > > > desktop ~three

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, Dec 14, 2021 at 11:27:07AM +0100, Emmanuel Vadot wrote: > On Tue, 14 Dec 2021 10:14:24 + Alexey Dokuchaev wrote: > > ... > > I know that I had problemless desktop some 10-5 years ago, okayish > > desktop ~three years ago, tolerable experience with 4.16.x DRM bits > > and shitty one

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, 14 Dec 2021 10:14:24 + Alexey Dokuchaev wrote: > On Tue, Dec 14, 2021 at 09:14:27AM +0100, Emmanuel Vadot wrote: > > On Tue, 14 Dec 2021 07:11:28 + Alexey Dokuchaev wrote: > > > ... > > > Oh, you know, it's about steadily deteriorating quality of our gfx > > > stack once we had

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, Dec 14, 2021 at 09:14:27AM +0100, Emmanuel Vadot wrote: > On Tue, 14 Dec 2021 07:11:28 + Alexey Dokuchaev wrote: > > ... > > Oh, you know, it's about steadily deteriorating quality of our gfx > > stack once we had started pulling things from Linux. > > Right. > That just proves that

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On 12/13, Gleb Smirnoff wrote: > On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote: > J> > J> So there are two things here. The root issue is that the devel/apr1 > port > J> > J> runs a configure test for TCP_NDELAY being inherited by accepted > sockets. > J> > J> This test panics

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, 14 Dec 2021 07:11:28 + Alexey Dokuchaev wrote: > On Mon, Dec 13, 2021 at 06:32:22PM +0100, Emmanuel Vadot wrote: > > On Mon, 13 Dec 2021 17:01:43 + Alexey Dokuchaev wrote: > > > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > > > > ... > > > > However, it was a