Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asynchronous forked workers with specs #220

Closed

Conversation

Inviz
Copy link
Contributor

@Inviz Inviz commented May 14, 2014

This is a follow up PR to #218. Sorry that it has got merged, but I don't see a better way to do without access to repo (which I don't really need).

  • It adds :asynchronous option to workers that lets them finish their stuff in background.
  • It adds work {} block, that will be executed in forked context, recieves worker output as argument
  • It allows forked workers to use sql, but they are forced to reconnect in that case
  • Async worker's work() returns pid that you can wait on, but it's not necessary.

It may be not rock solid, but I wrote specs and they pass.

Inviz added 4 commits May 14, 2014 08:13
To achieve that, all logging actions are moved out to the parent process, so child process only does the workload and marshals it back to parent process. Forked workers should NOT re-use parent connection (sanity check added).

The code makes use of exit!(0) command, that triggers fast exit from a forked process, so postgres does not close the forked connection.

Adds specs for forked workers success/failure, mixed workers, connection reuse exception.
…nt process and log completion with a newly established connection
@Inviz
Copy link
Contributor Author

Inviz commented May 14, 2014

I refactored some stuff to be more pretty. Also merged fix for the spec that always fails (connection count). Booya!

@pid = Process.pid
end

def needs_its_own_connection?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure the method name is right here. Shouldn't it be something like: new_fork?, forked?, just_forked? or something like that? Name is not clear enough until we read the actually code.

@jipiboily
Copy link
Contributor

I did not review the tests yet, gotta move on other stuff. I'll wait on feedback before continuing :)

Add Worker#kill_child hook
Add ConnAdapter#establish, #handle_fork
Add more comments regarding piping
Update comments to say that exit!(0) is a successful exit
@Inviz
Copy link
Contributor Author

Inviz commented May 20, 2014

Thank you @jipiboily for the meaningful comments! I updated PR to address all of them.

The comments regarding exit!(0) were unclear. That is an explicit way to exit the child process with successful status. So no zombie connections, I added more test.

And regarding the new block parameter in #work method, it is called within a forked process after the job is done. Tests use it to pass execution results back to main thread (as it allows now to do that manually) for assertions.

@Inviz
Copy link
Contributor Author

Inviz commented May 20, 2014

Ugh. I learned a thing or two about determinism in tests. I removed some assertions that caused race conditions.

@jipiboily
Copy link
Contributor

This has been stuck for a long time now. I think we should probably close it? 😕 Thoughts @senny ?

@senny
Copy link
Contributor

senny commented Aug 13, 2015

@jipiboily I'm not using forking workers. However if they are actually broken that isn't good. We should either fix it or remove broken functionality. Doesn't help to keep it around if it doesn't work and we are not fixing it.

@ukd1
Copy link
Contributor

ukd1 commented Jul 18, 2019

Closing, it's super old and not finished. @Inviz, lmk if you wanna re-open - I'd happily help you out.

@ukd1 ukd1 closed this Jul 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants