2 posts
furry-succotash - Jam Submission

My Jam project was to make a utility that I can see myself using for a long time.

I decided to recreate a simple utility program I made in Go before that re-runs specified command whenever any content in target directory changes, since I couldn't (or didn't try to) find a tool that does the same thing just like I wanted to.

after starting to work on my project I quickly realized that this isn't going well as I thought it would be. after struggling to transfer what I've wrote before into a C code for a week, this was the end result.

20211010_122252.mp4

through this jam project now I realized that I don't really know how to organize the code, and identify/decide what feature is crucial and should be implemented first.

I initially went to make it multi-threading but I totally forgot that multi-threading came in late when I wrote Go version before.

I didn't know that you cannot capture stdout concurrently without a workaround, since apparently a process created by CreateProcess with redirecting stdout to Pipe uses block buffering instead of line buffering (may be misunderstanding a bit).

I made several other mistake that can be boiled down into a lack of pre-planning or organizing. this experience made me realize that how un-organized I am while writing the code, and taught me what to pay attention for next time.

https://github.com/komugi1211s/furry-succotash

(project name was randomly generated)

Mārtiņš Možeiko
2380 posts / 2 projects
furry-succotash - Jam Submission
Edited by Mārtiņš Možeiko on

I didn't know that you cannot capture stdout concurrently

You do that by using overlapped reads - call ReadFile with OVERLAPPED structure in argument and it will do read in background. Then either periodically check completion result, or simply wait on it to finish it. Then you can process data and issue next read

since apparently a process created by CreateProcess with redirecting stdout to Pipe uses block buffering instead of line buffering (may be misunderstanding a bit).

This is not problem with process creation or pipes. This is purely choice of target application. It can decide when to do buffering or when not to do. Some applications will do line buffering when outputting to screen, and no buffering when to pipe. Some applications will always do buffering. Some will never do buffering. You (as somebody who creates process) does not control that. Application itself controls that. That's why, for example, python has extra argument you can pass when you want it to not buffer python -u script.py (u means unbuffered). This way it allows whoever called it to decide buffer or not.

2 posts
furry-succotash - Jam Submission