<FromGitter>
<636f7374> The first problem should be directly related to `-Dpreview_mt`.
<FromGitter>
<636f7374> I guess it may be because `.as` is used somewhere in Threads? I do nβt know, just guessing, I have encountered similar problems before.
<FromGitter>
<636f7374> The last prolbem seems to be related to `libEvent`? Or is it related to `-Dpreview_mt`?
<FromGitter>
<636f7374> The first problem is very similar to the problem I encountered before, which is the previous message.
<FromGitter>
<636f7374> these two (errors / problems / crashes) only happened once and I couldn't reproduce it again (stress testing the server with an Automator loop).
<FromGitter>
<636f7374> I'm a little disturbed by recent (errors / problems / crashes).
<FromGitter>
<636f7374> Anyone? Are all sleeping πͺ?
<FromGitter>
<636f7374> I want to go out, come back later. π£
Nicolab has quit [Quit: Leaving.]
Nicolab has joined #crystal-lang
<FromGitter>
<636f7374> I will be going out for awhile, Come back later. π£
HumanG33k has joined #crystal-lang
<FromGitter>
<Nicolab> @636f7374 Looks like a mistake with a pointer
<FromGitter>
<Nicolab> maybe a race condition.
<FromGitter>
<636f7374> @Nicolab Hi, Maybe, but I'm not familiar (Little is known) with `Thread`, `libEvent`, so I can't solve this problem.
<FromGitter>
<636f7374> @Nicolab I think so, otherwise it will have memory leaks, socket leaks and the like.
<FromGitter>
<636f7374> @Nicolab I did not find any socket leak or memory leak in the test.
<FromGitter>
<Nicolab> Ok I'm asking because the socket is closed and then tls_free does something about it.
<FromGitter>
<Nicolab> It's probably normal. I don't know tls_free.
<FromGitter>
<Nicolab> @636f7374 I could be wrong, but it looks like there's an IO copy on closed sockets.
<FromGitter>
<Nicolab> I don't have any other leads
<FromGitter>
<636f7374> @Nicolab If there is an error in reading / receiving, it will not release the context, it will release the memory manually after sending through the channel.
<FromGitter>
<Nicolab> I don't know if it changes in Crystal but in Go, in Go, in Rustet JS just counts the bytes.
<FromGitter>
<Nicolab> Bytes is an alias of `Slice(UInt8)`
<FromGitter>
<Nicolab> so `unless bytes.size`
<FromGitter>
<636f7374> @Nicolab No problem with `i32`, but better with `u8` :)
<FromGitter>
<Nicolab> Ok :)
<FromGitter>
<636f7374> @Nicolab Maybe I should remove `-Dpreview_mt` and test for a while.
<FromGitter>
<Nicolab> I'm out of ideas. I'm sorry.
<FromGitter>
<Nicolab> unbuffered_read which returns an i32
<FromGitter>
<636f7374> @Nicolab thank you for your help. :)
<FromGitter>
<Nicolab> :)
<FromGitter>
<Nicolab> good luck
<FromGitter>
<636f7374> I still think the problem is with the SuperSocket itself, even if the memory is manually free through the fiber, it may still be unsafe.
<FromGitter>
<636f7374> The best conclusion is: the error masks the callstack itself.
<FromGitter>
<636f7374> I always thought that Crystal could control memory like Rust, maybe I was wrong, it must use garbage collector to be safe.
<FromGitter>
<636f7374> I chose manual memory management (without finalizer) because I suspected that there was a memory leak somewhere, deadlock, and now I have solved all the problems.
<FromGitter>
<636f7374> In addition, using the garbage collector will cause a lot of memory consumption (It's just that memory usage is rising faster.)
<FromGitter>
<636f7374> This is what I say, I am going to eat :)
gangstacat has quit [Quit: Δis!]
gangstacat has joined #crystal-lang
duane has joined #crystal-lang
<FromGitter>
<Blacksmoke16> @grkek i replied
adam12_ is now known as adam12
sagax has quit [Quit: Konversation terminated!]
alexherbo23 has joined #crystal-lang
Guest94972 has quit [Ping timeout: 240 seconds]
alexherbo2 has quit [Ping timeout: 268 seconds]
alexherbo23 is now known as alexherbo2
Guest94972 has joined #crystal-lang
sagax has joined #crystal-lang
Nicolab has quit [Quit: Leaving.]
Nicolab has joined #crystal-lang
Nicolab has quit [Remote host closed the connection]
Welog has joined #crystal-lang
duane has quit [Ping timeout: 265 seconds]
<f1refly>
Is there a way to explicitly request an srv record when using Addrinfo?
<FromGitter>
<naqvis> f1refly, `AddrInfo` behind the scenes uses `LibC getaddrinfo` which is just an interface to hostname resolution service. So for querying DNS you would have to use some other shards (not sure if there are any available) or do your own crystal binding to some existing C libraries.
<f1refly>
Yeah I get that, I didn't know that the libc doesn't support srv
<f1refly>
I'll try to work around it then
alexherbo25 has joined #crystal-lang
Guest94972 has quit [Ping timeout: 268 seconds]
alexherbo2 has quit [Ping timeout: 268 seconds]
alexherbo25 is now known as alexherbo2
Guest94972 has joined #crystal-lang
<FromGitter>
<grkek> @Blacksmoke16 I replied as well ;)
<FromGitter>
<j8r> @Blacksmoke16 have you a Dockerfile that reproduces it?
Vexatos has quit [Remote host closed the connection]
Vexatos has joined #crystal-lang
_ht has joined #crystal-lang
duane has quit [Ping timeout: 268 seconds]
<FromGitter>
<wontruefree> I am sorry if you answered this but why is this a shard and not in the stdlib
<FromGitter>
<wontruefree> I am looking at the Issue but I dont see why this was not merged
<FromGitter>
<636f7374> @wontruefree Hey man, I checked your implementation of SOCKS5, I think there are some areas that can be improved, such as using `uninitialized` and `IO::Memory`? (I will make a SOCKS5 Proxy in the near future, I may refer to your shard and rewrite some content) :)
<FromGitter>
<wontruefree> feel free to use it :)
<FromGitter>
<wontruefree> I am glad you like it
<FromGitter>
<wontruefree> I am curious why did the stdlib resolver not get your resolver? It seems like there might be a problem?
<FromGitter>
<636f7374> @wontruefree In addition, this has some `WIP` (work in progress).
<FromGitter>
<636f7374> By the way, Crystal still doesn't support `HTTP2`, but `HTTP3` has been around for some time, which is `QUIC`.
<FromGitter>
<636f7374> Rust already has `QUIC` crates, even `Haskell` has been implemented (Third party).
<FromGitter>
<636f7374> As well as the `TCP Fast Open` (`TFO`) feature of TCPSocket, it seems that Crystal does not have this feature yet?
<FromGitter>
<636f7374> @wontruefree Crystal official is indeed preparing to implement a DNS resolver, but what they want to implement is: a threaded DNS resolver (based on `libEvent`), but I don't know why, and suddenly gave up.
<FromGitter>
<636f7374> @wontruefree All this information you can find in `Durian.cr` readme References.
<FromGitter>
<wontruefree> bummer
<FromGitter>
<wontruefree> It is work that needs to be done
<FromGitter>
<wontruefree> it would be nice if there was an issue where a roadmap was kept so at least people knew what was going on and if they wanted to help what they could do
duane has joined #crystal-lang
<jhass>
do what's fun to you! worst case it'll have to live on as a shard